Internet Engineering Task Force                 Integrated Services WG
INTERNET-DRAFT                                  S. Jackowski
draft-ietf-issll-isslow-svcmap-02.txt           Deterministic Networks
                                                D. Putzolu
                                                Intel Architecture Labs
                                                June 1998
                                                Expires:  1/99

            Network Element Service Specification for Low Speed Networks

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
   Directories on (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).

   This draft is a product of the Integrated Services Working Group of
   the Internet Engineering Task Force.  Comments are solicited and
   should be addressed to the working group's mailing list at int- and/or the author(s).


This document defines the service mappings for controlled load and
guaranteed services over low-bitrate networks.  These low-bitrate
networks typically include components such as analog phone lines, ISDN
connections and sub-T1 rate links. The document specifies the per-
network element packet handling behavior, parameters required, traffic
specification, policing requirements, and traffic ordering
relationships which are required to provide both Guaranteed and
Controlled Load service capabilities.  It also includes evaluation
criteria for elements providing the service.

This document is a product of the IETF ISSL working group and is based
on [1] and [2] which describe modifications to the PPP protocol to
enable these services.

Jackowski/Putzolu              Expires 1/99                     [Page 1]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt    June 1998

Table of Contents

1.  Introduction                                                                        3
2.  End to end Behavior                                                         4
3.  Motivation                                                                  5
4.  Network Element Data Handling                                 5
4.01   Rate and delay                                             6
4.02   Link Aggregation                                                     6
4.1    Controlled Load Versus Guaranteed Service                        7
4.2    Controlled Load and Guaranteed Service Data Handling             7
4.3    Controlled Load and Guaranteed Service Class Mapping       8
5.  Invocation Information                                                      9
6.  Exported Information                                                        9
7.  Policing                                                                    10
8.  Ordering and Merging                                                        10
9.  Guidelines for Implementors                                         10
9.1     Bit and Byte Stuffing Considerations                            10
9.2     Compression Considerations                                              11
9.3     Admission Control                                                       12
9.4     Fragment Scheduling Considerations                        13
10. Evaluation Criteria                                                         14
11. Security Considerations                                                     15
12. References                                                                  15
13. Authors' Addresses                                                          15

Jackowski/Putzolu                 Expires 1/99                  [Page 2]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt           June 1998

1. Introduction

With the proliferation of Internet usage in both businesses and homes,
there has been an explosion in demand for non-LAN access to the
Internet.  Most of these connections occur over dial up links.  There
has also been a recent surge in the usage of ISDN and other sub-
T1 rate connections.  Unfortunately, the nature of these 'low-bitrate'
links is that it is difficult to provide Quality of Service (QoS) when
there are multiple flows of data over the link.  For example, it is
virtually impossible for a user to receive consistent performance when
running a browser, a file transfer and an IP telephony application
simultaneously over a low speed link.

The ISSLOW subgroup of the ISSL working group has focused on defining
mechanisms to permit flow differentiation and QoS capabilities for mixed
traffic over low speed links.  This has been accomplished through a
series of extensions to the PPP protocol which permit fragmentation
and/or suspension of large packets in favor of packets on flows which
require QoS.  These protocol extensions are presented in [1] and [2].

This document describes the service mapping required to implement the
controlled load and guaranteed services over these PPP protocol
extensions.  It is modeled on the Network Element Service Specification
Template described in [3].  It is assumed that the ISSLOW Network
Element is one portion of a  PPP service available to the system.

Jackowski/Putzolu                Expires 1/99                   [Page 3]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

2. End-to-end Behavior

Unlike many of the other specific link layers addressed in the ISSL
working group, ISSLOW operates only over low speed point to point links
or connections.  Examples of these links include dial up lines, ISDN
channels, and leased lines.  As such,  'end to end' simply means between
two points.  In today's inter/intranet environment, this will include:

-       host to directly connected host.
-       host to/from network access device (router or switch).
-       Edge device (subnet router or switch) to/from router or switch.
-       In rare circumstances, the link may run from backbone router to
        backbone router.

Thus, the endpoints are two network elements as described above.  The
Controlled Load and Guaranteed services for ISSLOW links are applied on
the link between these elements and often represent the first or last
wide area hop in a true end to end service.  It is important to note
that these links tend to be the most 'bandwidth constrained' along the

ISSLOW services are only provided if both endpoints on the link support
ISSLOW.  This is determined during the PPP negotiation.  Because of the
unique characteristics of a point to point link with both endpoints
supporting ISSLOW, traffic is automatically shaped.  That is, incoming
traffic will be TSpec conformant, and except for some special
considerations for Guaranteed Service (below), the  admission control
function can make decisions based on local state: it does not need to
coordinate with the network element on the other end of the link.  As
described in [5], Guaranteed Service should approximate the
functionality of a leased  line.  Since ISSLOW runs over point to point
links, when rate control and delay bounds are provided for individual
flows, the link inherently acts like a leased circuit.

Thus, even for Guaranteed Service, because this hop is the most
bandwidth constrained, and because the connection is dual simplex
(e.g., not a shared link for send & receive), all admission control
decisions can be made locally.

Jackowski/Putzolu               Expires 1/99                     [Page 4]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt           May, 1997

3. Motivation

Previous sections described the motivation for the ISSLOW capabilities.
Dial up users are now treating their relatively low-bitrate connections
as they would a higher speed connection.  They are mixing multiple flows
of data and expect performance similar to what they see in a LAN
environment.  However, it is deployment of realtime applications which
is the primary motivation for hosts to implement Integrated Services.

In particular, IP Telephony, which has tight delay constraints for
commercial-level performance, produces small packets.  When these are
mixed with flows consisting of large packets (e.g. HTTP, FTP), delay
variance increases and absolute delay suffers as these small packets
wait in the queue behind even a single large packet being transmitted on
the link.  Because of the jitter tolerance and adaptive nature of codecs
used for packet voice and video, just providing a controlled load
service would satisfy most of the need for IP Telephony and other
realtime applications which are expected to run over low-bitrate

Another consideration in handling of packets over low speed links occurs
when looking at the end-to-end issues.  The low speed link is
usually just one hop on a longer path between endpoints.  As such, it is
usually the limiting factor in performance.  While this needs to be
considered in the host to router configuration, it becomes more critical
between edge devices and backbone routers where there is a multiuser
subnet as source and destination for traffic and a low-bitrate link to
the router.  To ensure some performance bounds end-to-end, guaranteed
service should be considered over these links even if it cannot be
offered end to end in the network.

4. Network Element Data Handling Requirements

The ISSLOW Network Service element may be implemented in hardware or
software.  As described in [1] and [2], for systems which can perform
bit-oriented transmission control, the suspend/resume approach optimizes
the available bandwidth by minimizing header overhead associated with
MLPPP fragmentation. For systems which provide frame-oriented
transmission control, the fragmentation approach can be implemented with
no hardware changes.  Choice of suspend/resume versus fragmentation
should be made based on the hardware's capability to handle the new HDLC
framing described in [1] and the system overhead associated with byte by
byte scanning (required by suspend/resume).

Jackowski/Putzolu                Expires 1/99                   [Page 5]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

To provide controlled load or guaranteed service with the suspend/resume
approach, when a packet for an IntServ admitted flow (QoS packet)
arrives during transmission of a best effort packet and continued
transmission of the best effort packet would violate delay constraints
of the QoS service flows, the best effort packet is preempted, the QoS
packet/fragments are added to the transmission, and the best effort
packet transmission is then resumed: usually all in one transmission.
The receiving station separates the best effort packet from the embedded
QoS fragments.  It is also conceivable that one IntServe Flow's packet
might suspend another flow's packet if the delivery deadline of the new
packet is earlier than the current packet.

For systems which use fragmentation,  since suspend/resume is not
possible, all packets longer than the maximum tolerable delay for an
IntServ packet are fragmented prior to transmission so that a short
packet for another flow can be interleaved between fragments of a large
packet and still meet the transmission deadline for the IntServ flow.

Note that the fragmentation discussed in this document refers to
multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications
as described in [1], not IP or other layer 3 fragmentation.  MLPPP
fragmentation is local to the PPP link, and does not affect end-to-end

4.01 Rate and Delay

ISSLOW assumes that the nature of point to point links is such that
rate, transmission time and delay are fixed and consistent.  The rate of
the link is determined at connection time, and the devices on the link
(adapters, modems, DSU/CSUs, etc) exhibit fixed delay characteristics.
Unfortunately this is not always true.

POTS modems can have varying rates, but the rate for a particular
POTS modem connection tends to converge over time to a particular
value as the modems adjust to line conditions.  Implementations
may need to adjust their admission control policies to reflect
this convergence.  Note that the value converged upon is frequently
higher  (usually about 10%)than the initial reported rate for a
connection - this means that admission control will  almost certainly
be overly conservative unless it takes this rate change into account.

In addition, tests with the V.42 protocol have shown that delay is also
not consistent.  Unfortunately it does not converge to a stable value
like the rate.  In fact, delay spikes may exceed the burst transmission
time which represents acceptable delay for Controlled Load (CL) Service.
Although the link delay term D is not used for CL admission or
scheduling, it may be useful to encorporate a bounded D term into
handling of CL flows over ISSLOW links.

4.02 Link Aggregation

Although certain link types, like ISDN, permit dynamic allocation of
Bandwidth across multiple links, it is assumed that the Admission
Control service will consider the impact of multiple physical links over
the point to point logical connection.

Note that because of the load balancing effect of Multilink PPP (MLPPP),
two 64 Kbps links should exhibit the delay and transmission
characteristics of a single 128 Kbps link.  However, MLPPP
implementations may approach load balancing and fragmentation
differently.  The mechanism used should be taken into consideration when
implementing the scheduler (especially token bucket) for packets,
fragments, and suspend/resume on top of existing MLPPP services to
ensure that adequate rate and delay characteristics are maintained.

Jackowski/Putzolu                Expires 1/99                   [Page 6]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

4.1 Controlled Load versus Guaranteed Service

With most link layers, Guaranteed Service requires more tightly
controlled service by the Network Element, and in most cases, acceptance
of a Guaranteed Service request results in over-provisioning of link
level resources.  Controlled Load (CL) Service is usually less
constrained and permits more flexibility in scheduling of packets for
the link.

Controlled Load requires that the delay associated with packet
transmission be 'closely equivalent to unloaded best effort service.'
Because ISSLOW operates over point to point links, unloaded best effort
service means that best effort packets will incur no more than burst
packet delay: M/r where M is the maximum packet size and r is the
transmission rate.   Thus maximum permitted delay for a Controlled Load
packet (CLmDELAY) is bounded by M/r + P/r where P is the size of the
outgoing packet.

4.2 Controlled Load and Guaranteed Service Data Handling

Upon arrival of a QoS flow's packet, the ISSLOW Network Element
determines if the packet is conformant.  If it is not, Policing is
applied (see Policing).  Conformant means:

1) The flow does not exceed the associated TSpec peak rate (RSpec rate
for Guaranteed Service: rT+b with T=time period).
2) The packet does not cause a token bucket overflow.

If the packet is conformant, it is compressed as required, fragmented
(if necessary), and scheduled.  If there is no conflicting best effort
traffic, the packet is queued along with the rest of conformant QoS
traffic and scheduled with respect to any other IntServ flows such that
its transmission deadline is met.

For the suspend/resume implementation to achieve controlled load, any
packets being transmitted whose transmission would violate
the CLmDELAY are suspended.  Otherwise, the QoS packet/fragments are
scheduled ahead of any queued best effort traffic.

Jackowski/Putzolu                Expires 1/99                   [Page 7]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

For  CL Fragmentation implementations, the packet/fragment is scheduled
ahead of any best effort packets.  Note that all best effort packets
must be divided into fragments less than or equalto the smallest MRU
(or associated fragment size) of all the QoS flows.  This incurs at
most one fragment delay for the QoS traffic: closely equivalent to
unloaded best effort service.

For Guaranteed Service for both Fragmentation and suspend/resume, the
scheduler determines if continued transmission of the best effort packet
being transmitted would cause delay greater than the acceptable delay.
If so, the best effort packet is preempted or, in the case of
fragmentation, the QoS packet is scheduled ahead of the rest of the
best effort packets' fragments.

4.3 Controlled Load and Guaranteed Service Class Mapping

To provide consistent signalling across point to point links, it
is important to identify and characterize the flows consistently
on each end of the link.  Ideally, both ends would use similar
scheduling mechanisms as well.  The coordination of flow identification
and scheduling can be achieved easily with the new MLPPP
class mappings [1].

Depending on the sequence number option chosen in the MLPPP negotiation,
there are either 2 bits (short sequence numbers) or 4 bits (long
sequence numbers) available for class identification.

Following the model of other working subgroups, traffic classes should be
mapped as follows:

Traffic Type          MLPPP Class (short)     MLPPP Class (long)

Best Effort                   0                       0
non-conformant                0                       1
Controlled Load               1                       4
Guaranteed (10ms)             2                       5
Guaranteed (100ms)            3                       6

Jackowski/Putzolu                Expires 1/99                   [Page 8]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

5. Invocation Information

To invoke Controlled Load and Guaranteed Services, both traffic
characteristics and the flow itself must be identified to the Network
Element.  Several methods can be employed to identify the flows. For
RSVP, filtering can be used to identify the flows.  For non-RSVP
implementations, mechanisms such as the FlowID field in IP Version 6, or
the TOS field in IP version 4 can be used.  As described above, the
Network Element can then use the specified values to  apply the
appropriate QoS and to map the flows to a particular class.

A number of major router and switch vendors currently support use of
the TOS bits to signal priority and class of service.  As a result,
applications and host proxies have been developed to enable users and
network managers to apply policies requesting differential services via
TOS.  Use of these bits is the easiest way to identify flows without
the overhead of filtering.

It is therefore strongly recommended that the Network Service Element
support mapping of the IP Precedence bits of the TOS field to MLPPP
classes described in [1] as follows:

IP Precedence Value     Multiclass - short seq          Multiclass - long seq

        0                                       0                                       0
        1                                       0                                       1
      2 or 3                        0                             2 or 3
        4                                       1                                       4
        5                                       2                                       5
        6 or 7                          3                                       6 or 7

Note that use of the TOS field or of the FlowID field does not preclude
prefix elision.  The Network Service Element can map the TOS or FlowID
to a MLPPP class, elide the prefix before transmission, and the prefix
(with TOS or FlowID) will be reapplied by the receiver.

If the Network Service Element is running on a system that doesn't
support application or proxy use of the TOS or FlowID fields, then
filtering must be applied and:

As described in [4], Controlled Load Service is invoked by specifying
the flow's traffic characteristics through a TSpec (see [5]).

As described in [5], Guaranteed Service is invoked by specifying the
flow's TSpec and a requested reservation via an RSpec (see [6]).

6. Exported Information.

For Controlled Load Service, there is no requirement to export

For Guaranteed service, both C and D terms for delay computations must
be made available for export through the Adspec or other means.  See
Sections 9.1 (Admission Control) for guidelines on computing the C and D

See [4] and [5] for additional information on Exported Information.

Jackowski/Putzolu                Expires 1/99                   [Page 9]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

7. Policing

Policing is applied to non-conformant QoS traffic and to best effort
traffic whose transmission would violate the Controlled Load or
Guaranteed Service constraints.  This document does not designate a
specific packet scheduling implementation.  Ideally, best effort traffic can be
serviced through separate queues and a weighted queuing mechanism, or when a
conflict with QoS traffic arises, best-efforts traffic can simply be discarded.

Both Controlled Load and Guaranteed Services permit scheduling of non-
conformant traffic as well as the option to discard non-conformant
packets.  See [4] and [5] for additional information on policing options
for Controlled Load and Guaranteed Services.

8. Ordering and Merging

Refer to [4] and [5] for TSpec and RSpec ordering and merging

9. Guidelines for Implementors

9.1 Bit and Byte Stuffing Considerations

Certain kinds of low bandwidth links present special challenges in providing
controlled load and guaranteed service even when the ISSLOW protocols are
used. These challenges are documented here as a caution to implementers to
prevent use of overly optimistic admission control policies.

One important consideration in provisioning any PPP link is reductions in
available link rate due to bit stuffing. Typical bit stuffing algorithms
can result in as much as 20% additional overhead. Thus, admission control
algorithms for guaranteed service over links where bit stuffing can take place
should take the RSpec rate of all flows and multiply by 1.2 in determining
whether a new flow can be admitted or not. Admission control algorithms for
controlled load reservations may use a similar algorithm using the TSpec peak
rate or may attempt to measure the actual degree of expansion occurring on a
link due to bit stuffing. This characterization can then be used to adjust
the calculated remaining link capacity. Such algorithms must be used
cautiously, in that the degree of bit stuffing occurs may vary significantly,
both in an inter- and intra-flow fashion.

Byte stuffing is also found on many PPP links, most frequently on POTS modems
when using the v.42 protocol. Byte stuffing poses a difficult problem to
admission control, particularly in the case of guaranteed service, due to
its highly variable nature. In the worse case, byte stuffing can result in
a doubling of frame sizes. As a consequence, a strict implementation of
admission control for guaranteed load on byte stuffed PPP links should double
RSpec of link traffic in making flow admission decisions. As with bit
stuffing, implementations of controlled load service admission control
algorithms for links with byte stuffing may attempt to determine average
packet expansion via observation or may use the theoretical worst case values.

Jackowski/Putzolu                Expires 1/99                   [Page 10]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

In addition to PPP bit- and byte stuffing, other protocols used in POTS
modems also have ramifications on link capacity. The v.34 protocol, for
instance, is adaptive to link conditions, and is able to recalibrate its
transmission rate multiple times over the duration of a connection.
Typically this re-calibration will result in a small (~10%) increase in
transmission rate over the initial connection within the first minute of
a call. It is important to note, however, that other results are possible
as well, including decreases in available bandwidth. Admission control
algorithms must take such changes into consideration as they occur, and
implementations must be designed to gracefully handle the pathological case
where link rate actually drops below the currently reserved capacity of a link.

The v.42 protocol is another potential troublesome area in implementing
integrated services over low bandwidth links. This protocol, which provides
link layer reliability via retransmission, can result in frames experiencing
unpredictable delays in transiting such a link. Retransmissions also
implicitly steal link bandwidth from other traffic. These delays and
reductions in link bandwidth make it extremely difficult to honor a
guaranteed service reservation. On a link that is actually lightly or
moderately loaded, a controlled load service can to some extent accept
such events as part of the behavior of a lightly loaded link. Unfortunately,
as actual link utilization increases, v.42 retransmissions have the
potential of stealing larger and larger fractions of available link bandwidth;
making even controlled load service difficult to offer at high link utilization
when retransmissions occur.

Finally, the framing method must be factored into the overhead associated with
link level tramsmission.  If fragmentation is used, the overhead associated with
fragment headers must be included in the admission control calculations below.
If suspend/resume is used, the additional framing overhead for inserted packets
must also be calculated.

9.2 Compression Considerations

The ISSLOW specification supports several PPP options.  When deciding
whether to admit a flow, Admission Control must compute the impact of
the following on MTU size, rate, and fragment size:

Header compression: Van Jacobson or Casner-Jacobsen.
Prefix Elision.
Fragment header option used.
Fragmentation versus suspend/resume approach.

If any of the compression options are implemented for the connection,
the actual transmission rate, and thus the bandwidth required of the
link, will be reduced by the compression method(s) used.

Prefix elision can take advantage of mapping flows to MLPPP classes
to elide prefixes which cannot be compressed at higher layers.  By
establising agreement across the link, the sender may elide a prefix for
a certain class of traffic and upon receiving packets in that class, the
receiver can restore the prefix.

Both compression gain and elision gain must be included as described in
the admission control section below.

Jackowski/Putzolu                Expires 1/99                   [Page 11]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

9.3 Admission Control

Admission Control must decide whether to admit a flow based on rate and
delay.  Assume the following:

LinkRate is the rate of the link.
MTU is the maximum transmission unit from a protocol.
MRU is the maximum receive unit for a particular link.
CMTU is the maximum size of the MTU after compression is applied.
eMTU is the maximum effective size of the MTU after fragmentation.
FRAG is the fragment size including MLPPP header/trailers.
Header is the size of the header/trailers/framing for MLPPP/Fragments.
pHeader is the additional header/framing overhead associated with
        suspend/resume.  This should include FSE and worst case stuffing
pDelay is the delay associated with suspend/resume packets.
b is the bucket depth in bytes
R is the requested Rate.
D is the fixed overhead delay for the link (Modem, DSU, etc).
C is the delay associated with transmission and fragmentation.
eRate is the effective rate after compression and fragmentation.

The D term may be configured by an administrative tool once the network
is installed; it may be computed using the Adspec or other realtime
measurement means; or it may be available from hardware during link
setup and/or PPP negotiation.

Admission Control must compute CMTU, eMTU, and eRate for Controlled Load
Service, and it must compute CMTU, eMTU, eRate, and C for Guaranteed

To determine whether the requested rate is available, Admission Control
must compute the effective rate of the request (eRate) - worst case - as

#_of_Fragments = (CMTU + FRAG)/(FRAG-Header)

eMTU = (#_of_Fragments) * FRAG

eRate = eMTU/CMTU * R

Admission Control should compare the eRate of the request against the
remaining bandwidth available to determine if the requested rate can be

For Controlled Load Service,  a flow can be admitted as long as there is
sufficient bandwidth available (after the above computation) to meet the
rate requirement, and if there is sufficient buffer space (sum of the
token bucket sizes does not exceed the buffer capacity).  While some
statistical multiplexing could be done in computing admissability, the
nature of the low-bitrate links could make this approach risky as any
delay incurred to address a temporary overcommitment could be difficult
to amortize.

Jackowski/Putzolu                Expires 1/99                   [Page 12]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

Guaranteed Service requires  delay computations.  These computation are
based on the standard formula for delay:

Delay = b/R + C/R + D

Note that for suspend/resume, an additional term is required:

pDelay = b/R + C/R + D + pHeader/R.

This term exists because of the additional overhead associated with the
suspend/resume headers created when suspending a packet.  In the worse
case, every transmission of a QoS packet could require suspension of a
best effort packet and thus incur the overhead.  In most networks, this
term will be nominal at most.  However, on some low-bitrate links, the
overhead may be worth computing.

Since MLPPP includes fragmentation, the C term is not fixed and must be
represented by the worse case fragmentation as computed in the effective
MTU size:

C = eMTU.

Note that because ISSLOW runs on point to point links, Guaranteed
Service can be offered over a link without any negotiated agreement from
the next hop.  However, if these services are used in conjunction with
RSVP, the C and D values above should be used in the Adspec.

9.4 Fragment Scheduling Considerations

As described in Section 4, large packets should be fragmented to a size
sufficiently small to allow higher priority flows to get a hold of the
line quickly enough to not violate their reservation constraints.  As
such, the upper bound for fragment sizes should be no larger than the
smallest MTU of all QoS flows.  While a very small fragment size
is desirable from the point of view of efficient link utilization, the
overhead associated with highly granular fragmentation makes it
necessary to strike a balance between these considerations. While this
document will not specify a particular scheduling algorithm, the
following example should help illustrate the issue:

Assume we have three different priority flows, A, B, and C.
A is higher priority than B, B higher than C
(and of course it is transitive). Packets from flow C take
100ms, flow B takes 30ms, and flow A takes 30ms to transmit. B's
required maximum latency is 70ms, while A's is 50ms.  The above scenario
results in flowsB and C needing to be segmented into 20ms long fragments -
that way a lower priority frame will hold the link at most
20ms before A gets to the link, taking another 30ms to transit,
totaling 50ms - all well and good.   B has a problem, however -
in the scenario where a fragment from C is just starting
to transmit the link when packets from A and B arrive (call
this time 0). The fragment from C will transmit until time 20ms.
After that, the A packet will transmit - finishing by time 50ms,
just in time. At this point, the fragment from B starts to
transmit - taking 30ms more, finishing by time 80ms (thus violating
its reservation).

Jackowski/Putzolu                Expires 1/99                   [Page 13]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

The important point above the scenario is not that it is possible
to underprovision a link, but that a link can be underutilized
by using too large a fragment size - in the above case, a 10ms
fragment size would have allowed both A and B to honor their
reservations, a 20ms size does not.

10. Evaluation Criteria

For Controlled Load Service, the ISSLOW network element must ensure that
the service requested via the TSpec is delivered to the requesting QoS
flow such that the PPP link appears to be a 'lightly loaded link.

As a baseline, it is suggested that performance measurements on
throughput, delay, and packet error measurements be performed on an
unloaded link with just the QoS flow using various packet sizes.  The
baseline should measure performance for both conformant and non-
conformant traffic when for  overloading the link with a single flow.
Once these measurements are complete, measurements of the
Controlled Load Service should be performed as follows:

1) Request QoS flows in the presence of best effort traffic and ensure
that the QoS flows' performance approximate the unloaded baseline

2) Request QoS flows whose aggregate throughput would exceed the link
capacity.  Admission Control should deny these service requests or admit
them as best effort only.

3) Generate traffic on a QoS flow which exceeds its TSpec commitment.
Ensure recovery of the flow once the traffic becomes conformant.

For Guaranteed Service:

1) Ensure that Admission Control will deny service requests or convert
them to best effort when link capacity or delay bounds would be

2) On a best-efforts loaded link, ensure that the number of lost packets
does not exceed those established in the baseline measurements.

3) On a best-efforts loaded link, ensure that delay and rate commitments
can be met for QoS flows.

4) With multiple QoS flows, ensure that an admission of additional QoS
flows does not cause a violation in rate, error rate, or delay
constraints of any QoS flow.

Jackowski/Putzolu                Expires 1/99                   [Page 14]

INTERNET-DRAFT   draft-ietf-issl-isslow-svcmap-03.txt   June 1998

11. Security Considerations

Security considerations for PPP links are the subject of other working
groups.  However, with respect to providing quality of service over PPP
links, it is important to note that relying on observed average packet expansion
during admission control, due to bit- or byte stuffing
introduces a potential vulnerability to denial of service attacks. An adversary
could intentionally send traffic that will result in worst case bit- or byte
stuffing packet expansion, which could in turn result in quality of service
guarantees not being met for other flows. This potential denial of service
attack argues strongly for using a worst case expansion factor in admission control
calculations, even for controlled load service.

12. References

   [1] C. Bormann "The Multi-Class Extension to Multilink PPP"
   Internet Draft, July 1997, <draft-ietf-issl-isslow-mcml-03.txt>

   [2] C. Bormann "PPP in a real-time oriented HDLC-like framing"
   Internet Draft, July 1997, <draft-ietf-issl-isslow-rtf-03.txt>

   [3] rfc2216 -- Network Element Service Specification Template. S.
   Shenker, J. Wroclawski. September 1997

   [4] rfc2211 -- Specification of the Controlled-Load Network
   Element Service. J. Wroclawski. September 1997

   [5] rfc2212 -- Specification of Guaranteed Quality of Service. S.
   Shenker, C. Partridge, R. Guerin. September 1997

   [6] rfc2215 -- General Characterization Parameters for Integrated
   Service Network Elements. S. Shenker, J. Wroclawski. September 1997.

13 Author's Address:

   Steve Jackowski
   Deterministic Networks, Inc.
   245M Mt Hermon Rd, #140
   Scotts Valley, CA  95060

   David M. Putzolu
   Intel Architecture Labs (IAL)
   2111 NE 25th Avenue
   Hillsboro, OR 97124-5961
   (503) 264-4510

Jackowski/Putzolu                       Expires 1/99            [Page 15]