RFC relevance of services

As per Relevance of the word services, we have this rfc below:

Network Working Group S.
Request for Comments: 2688 Deterministic
Category: Standards Track D.
Intel Architecture
E.
Argon
B.
Cisco
September 1999

Integrated Services Mappings for Low Speed

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

A set of companion documents describe an architecture for
integrated services over low-bitrate links, such as modem lines,
B-channels, and sub-T1 links [1, 2, 3, 4]. The main components of
architecture are: a set of real-time encapsulation formats
asynchronous and synchronous low-bitrate links, a header
architecture optimized for real-time flows, elements of
protocols used between routers (or between hosts and routers),
announcement protocols used by applications to allow this
to take place

This document defines the service mappings of the IETF
Services for low-bitrate links, specifically the controlled load [5]
and guaranteed [6] services. The approach takes the form of a set
guidelines and considerations for implementing these services,
with evaluation criteria for elements providing these services

Jackowski, et al. Standards Track [Page 1]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

1.

In addition to the "best-effort" services the Internet is well-
for, other types of services ("integrated services") are
developed and deployed in the Internet. These services
special handling of traffic based on bandwidth, latency, and
requirements that cannot usually be met using "best-effort" service

This document defines the mapping of integrated services "
load" [5] and "guaranteed" [6] services on to low-bandwidth links
The architecture and mechanisms used to implement these services
such links are defined in a set of companion documents.
mechanisms defined in these documents include both compression
flows (for bandwidth savings) [4,10] and a set of extensions to
PPP protocol which permit fragmentation [2] or suspension [3]
large packets in favor of packets from flows with more
service requirements

1.1. Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [11].

2. Issues for Providing Controlled and Guaranteed

Unlike other link layers, the links referred to in this
operate only over low speed point to point connections. Examples
the kinds of links addressed here include dial-up lines,
channels, and low-speed (1.5Mbps or less) leased lines. Such
can occur at different positions within the end-to-end path

- 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, a link from backbone router to
router

These links often represent the first or last wide area hop in a
end to end service. Note that these links may be the most
constrained along the path between two hosts

The services utilized in mapping integrated services to these
are only provided if both endpoints on the link support
architecture and mechanisms referenced above. Support for
mechanisms is determined during the PPP negotiation. The non-

Jackowski, et al. Standards Track [Page 2]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

nature of these links, along with the fact that point-to-point
are typically dual simplex (i.e., the send and receive channels
separate) allows all admission control decisions to be made locally

As described in [2] and [3], for systems that can exert real
control of their transmission at a finer grain than entire
frames, the suspend/resume approach optimizes the available
by minimizing header overhead associated with MLPPP pre-
and can provide better delay. However, this comes at the expense
preparing all outgoing data and scanning all incoming data
suspend/resume control information. The fragmentation approach
be implemented without additional scanning of the data stream (
bit-/byte-stuffing, which may be in hardware) and is applicable
systems which provide only frame-oriented transmission control
Choice of suspend/resume versus fragmentation should be made based
the level of transmission control, the element's capability to
the HDLC-like framing described in [2], and the system
associated with byte by byte scanning (required by suspend/resume).

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

For systems which use fragmentation, any packets longer than
maximum tolerable delay for packets from enhanced service flows
fragmented prior to transmission so that a short packet for
flow can be interleaved between fragments of a larger packet
still meet the transmission deadline for the flow requiring
services

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

Jackowski, et al. Standards Track [Page 3]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

2.1 Calculating "Acceptable Delay" for Int-serv

A router which provides Controlled Load or Guaranteed Service over
low speed serial link needs to have some notion of the "
delay" for packets that belong to int-serv flows. If
fragmentation, a router needs to know what size to fragment
to; if using suspend/resume, it needs to know when it is
to suspend one packet to meet the delay goals of another

Unfortunately, there is no hard and fast way for a single delay
to be determined for a particular flow; while the end-points of
flow have enough information to determine acceptable end-to-end
bounds and to make reservation requests of the network to meet
bounds, they do not communicate a "per-hop" delay to routers

In the case of Guaranteed Service [6], one approach is to let
network operator configure parameters on the router that
directly affect its delay performance. We observe that
service allows routers to deviate from the ideal fluid flow model
to advertise the extent of the deviation using two error terms C
D, the rate-dependent and rate-independent error terms, defined
[6]. A network operator can configure parameters of the low
link in such a way that D is set to a value of her choice

If link-level fragmentation is used, the router controlling a low
speed link can be configured with a certain fragment size. This
enable a component of the error term D to be calculated based on
time to send one fragment over the link. (Note that D may have
components such as the speed of light delay over the link.)
of the calculation of D are described below. Similarly,
suspend/resume is used, the router may be configured with a
parameter, which would enable it to decide when it was appropriate
suspend a packet

For Controlled Load, there are no error terms, and the router
decide how best to meet the requirements of the admitted
using only the information in their TSpecs. Since the definition
Controlled Load states that a CL flow with Tspec rate r
receive treatment similar to an unloaded network of capacity r,
packets should not generally experience end-to-end
significantly greater than b/r + propagation delays. Clearly a
connected to a low speed link should not introduce a delay
than b/r due to transmission of other fragments; ideally it
introduce substantially less delay than b/r, since other hops on
end-to-end path may introduce delay as well. However, this may
difficult for flows with very small values of b

Jackowski, et al. Standards Track [Page 4]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

It is expected that implementers will make their own tradeoffs as
how low to make the delay for Controlled Load flows. Similarly,
may not be possible or desirable to configure the
affecting D to arbitrarily small values, since there is a cost
overhead in fragmenting packets to very small sizes. Conversely, if
is too large, some applications may find that they cannot make
reservation that will meet their delay objectives

For the remainder of this document, we assume that a router has
notion of the acceptable delay that it may introduce before
transmission of a packet. This delay is in addition to any delay
a packet might be subjected to as a result of the "ideal"
algorithm that the router uses to schedule packets

3. Controlled Load and Guaranteed Service Class

Supporting integrated services over PPP links which implement MCML
RTF can be accomplished in several ways. Guidelines for
these services to PPP links and to the classes provided by
suspend/resume and fragmentation mechanisms are presented below
Note that these guidelines assume that some sort of
protocol is used to indicate desired quality of service to both
sender and receiver of a flow over a PPP link

3.1 Predefined Class

A relatively simple method of class mapping that MAY be used is
where class values correspond to predefined levels of service.
this arrangement, all admitted flows are grouped into one of
buckets, where each bucket roughly corresponds to the level
service desired for the flows placed in it. An example set
mappings appears below

MCML Short MCML Long RTF

0b00 0b0000 0b000 Best
NA 0b0001 0b001
0b01 0b0010 0b010 Delay Sensitive, no
NA 0b0011 0b011
NA 0b0100 0b100
0b10 0b0101 0b101 Delay Sensitive, 500ms
NA 0b0110 0b110 Delay Sensitive, 250ms
0b11 0b0111 0b111 Network

Table 1: Example Mappings of Classes to

Jackowski, et al. Standards Track [Page 5]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

Note that MCML has two formats, short sequence numbers, and
sequence numbers, that allow for 2 and 4 bits of class identification
RTF allows for 3 bits of class identification in all formats

Using a default-mapping method of assigning classes to flows in
fixed fashion comes with certain limitations. In particular, all
which fall within a particular bucket (are assigned to a
class) will be scheduled against each other at the granularity
packets, rather than at the finer grained level of fragments.
can result in overly conservative admission control when the number
available classes is small such as in MCML short sequence
format

3.2 Predefined Class Mappings and Prefix

In the case where fewer reservations are expected than the
number of classes negotiated for a PPP link, it is possible to
individual flows to fixed class numbers. This assignment is useful
the case where the protocol identifier associated with one or
flows is known at LCP negotiation time and the bandwidth of
connection is relatively small. If these conditions hold true,
for those flows that are known, a specific class can optionally
assigned to them and the prefix elision PPP option [2] can be used
those classes to achieve a small bandwidth savings

3.3 Dynamic Class

In the case where predefined class mappings are not satisfactory,
implementer MAY map class values to individual packets rather
assigning flows to fixed classes. This can be done due to the
that the classes that MCML and RTF provide can be viewed purely
PPP-specific segmentation/fragmentation mechanisms. That is, while
class number MUST remain constant on an intra-packet basis, it
vary on an inter-packet basis for all flows transiting a
link. Actual assignment of particular flows to fixed classes
unnecessary, as the class numbers are NOT REQUIRED to have any
other than in the context of identifying the membership
fragments/segments as part of a single packet. This point
sufficiently important that an example is provided below

Consider a PPP link using the MCML short sequence number
format (that is, four classes are provided). Assume that in
to carrying best effort traffic, this link is carrying five
service flows, A, B, C, D, and E. Further assume that the
capacity is 100kbit/s and the latency is 100ms. Finally, assume the
traffic is sufficient to keep the pipe full at all times and that
flows A-E are each 10kbit/s and all have delay bounds of 145ms

Jackowski, et al. Standards Track [Page 6]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

Time(ms)
0 BE traffic is queued
0 2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...)
8 2kbit fragment from BE sent, cls 0 (10kbit BE packet done
9 8kbit packet from flow A
10 2kbit fragment from A sent, cls 1 (8kbit flow A packet start
11 8kbit packet from flow B
12 2kbit fragment from B sent, cls 2 (8kbit flow B packet start
13 8kbit packets from flows C, D, and E
14 2kbit fragment from C sent, cls 3 (8kbit flow C packet start
16 2kbit fragment from D sent, cls 0 (8kbit flow D packet start
18 2kbit fragment from A sent, cls 1
20 2kbit fragment from B sent, cls 2
22 2kbit fragment from A sent, cls 1
24 2kbit fragment from A sent, cls 1 (8kbit flow A packet done
26 2kbit fragment from E sent, cls 1 (8kbit flow E packet start
27 8kbit packet from flow A
28 2kbit fragment from B sent, cls 2
30 2kbit fragment from C sent, cls 3
32 2kbit fragment from E sent, cls 1
34 2kbit fragment from B sent, cls 2 (8kbit flow B packet done
36 2kbit fragment from E sent, cls 1
38 2kbit fragment flow A sent, cls 2 (8kbit flow A packet start
(etc.)

This example shows several things. First, multiple flows MAY
the same class, particularly in the case where there are more
than classes. More importantly, there is no reason that a
flow must be assigned to a fixed class - the only requirement is
each packet, when fragmented, MUST have the same class value
to all fragments. Beyond this requirement the link scheduler
assign individual to changing class numbers as necessary to
reservation requirements

One suggestion to implementers of integrated services on MCML and
links using dynamic mappings is that all BE traffic SHOULD
logically separated from QoS traffic, and mapped to a
(MCML classes 0-3 in short sequence number fragment format, 0-15
long sequence number fragment format) or suspendable (RTF classes 0-
6) class. Since BE traffic will in most implementations not
scheduled for transmission except when a link is empty (that is,
CL or GS traffic is ready for transmission), implementers MAY
to make use of class number 0 for BE traffic

Jackowski, et al. Standards Track [Page 7]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

3.4 Non-Conformant

Treatment of non-conformant QoS traffic is largely determined by
appropriate service specifications, but the detailed
in the context of this draft allows for some flexibility.
of flows containing non-conformant traffic SHOULD always be done
the level of granularity of individual packets rather than at a
grained level. In particular, in those cases where a network
scheduling flows for transmission needs to drop non-
traffic, it SHOULD drop entire packets rather than
individual fragments of packets belonging to non-conformant traffic
In those cases where a network element forwards non-
traffic when link bandwidth is available rather than dropping
traffic, the implementation SHOULD fragment packets of such
as if it were best effort traffic

Whether BE and non-conformant traffic are treated differently
regards to transmission (e.g., BE is given priority access over non
conformant traffic to the link) or whether within each type
traffic special treatment is afforded to individual flows (e.g., WFQ
RED, etc.) is service dependent

4. Guidelines for

4.1. PPP Bit and Byte Stuffing Effects on Admission

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

Byte stuffing is also used on many PPP links, most frequently on
modems when using the v.42 protocol. Byte stuffing poses a
problem to admission control, particularly in the case of
service, due to its highly variable nature. In the worse case,
stuffing can result in a doubling of frame sizes. As a consequence,
strict implementation of admission control for guaranteed load

Jackowski, et al. Standards Track [Page 8]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

byte stuffed PPP links SHOULD double the RSpec of link traffic
making flow admission decisions. As with bit stuffing
implementations of controlled load service admission
algorithms for links with byte stuffing MAY attempt to
average packet expansion via observation or MAY use the
worst case values

4.2. Compression

The architecture for providing integrated services over low
links uses several PPP options to negotiate link configuration
described in [4, 8, 10]. When deciding whether to admit a flow
admission control MUST compute the impact of the following on
size, rate, and fragment size

Header compression: Van Jacobson or Casner-Jacobson [4,8,10].
Prefix Elision
CCP
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
link, will be reduced by the compression method(s) used

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

Both compression gain and elision gain MUST be included as
in the admission control section below. Note that the ability
perform compression at higher layers (e.g. TCP or RTP/UDP) may
on the provision of a hint by the sender, as described in [9].

4.3. Admission

Admission control MUST decide whether to admit a flow based on
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 effective size at the link layer of an MTU-sized
after link layer fragmentation and addition of the fragment headers
FRAG is the fragment size including MLPPP header/trailers

Jackowski, et al. Standards Track [Page 9]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

Header is the size of the header/trailers/framing for MLPPP/Fragments
pHeader is the additional header/framing overhead associated
suspend/resume. This should include FSE and worst case
overhead
pDelay is the time take to suspend a packet already "in flight",
e.g. due to the delay to empty the output FIFO
b is the bucket depth in
R is the requested Rate
Dlink is the fixed overhead delay for the link (Modem, DSU
speed-of-light, etc).
eRate is the effective rate after compression and fragmentation

The Dlink term MAY be configured by an administrative tool once
network is installed; it may be determined by real-time
means; or it MAY be available from hardware during link setup and/
PPP negotiation. Refer to Appendix A for more considerations on
link characteristics and delays

Admission control MUST compute CMTU, eMTU, and eRate for
Load Service, and it MUST compute CMTU, eMTU, eRate, and D
Guaranteed Service

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

#_of_Fragments = CMTU div (FRAG-Header) [Integer divide
Last_Frag_Size = CMTU mod (FRAG-

If Last_Frag_Size != 0
eMTU = (#_of_Fragments) * FRAG + Last_Frag_Size +

eMTU = (#_of_Fragments) *

eRate = eMTU/CMTU * R [floating point divide

Admission control SHOULD compare the eRate of the request against
remaining bandwidth available to determine if the requested rate
be delivered

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

Jackowski, et al. Standards Track [Page 10]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

4.4 Error Term

Guaranteed Service requires the calculation of C and D error terms.
is a rate-dependent error term and there are no
considerations affecting its calculation in the low-speed
environment. The D term is calculated from the inherent link
(Dlink) plus the potential worst case delay due to transmission
another fragment or suspend/resume overhead. Thus, D should
calculated

D = Dlink + FRAG/

in the case of a fragementing implementation

D = Dlink + pHeader +

for a suspend/resume implementation

4.5 Scheduling

We may think of the link scheduler as having two parts, the first
which schedules packets for transmission before passing them to
second part of the scheduler -- the link level scheduler -- which
responsible for fragmenting packets, mapping them to classes,
scheduling among the classes

In the dynamic class mapping mode of Section 3.3, when deciding
class to assign a packet to, the link level scheduler should
account of the sizes of other packets currently assigned to the
class. In particular, packets with the tightest delay
should not be assigned to classes for which relatively large
are in the process of being transmitted

In either the dynamic or the static class mapping approach, note
the link-level scheduler SHOULD control how much link bandwidth
assigned to each class at any instant. The scheduler should
bandwidth to a class according to the bandwidth reserved for the
of all flows which currently have packets assigned to the class.
that in the example of Section 3.3, when packets from flows A and
were assigned to the same class (class 1), the scheduler
more bandwidth to class 1, reflecting the fact that it was
traffic from reservations totaling 20kbit/s while the other
were carrying only 10kbit/s

Jackowski, et al. Standards Track [Page 11]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

5. Security

General security considerations for MLPPP and PPP links are
in RFC 1990 [12] and RFC 1661 [13], respectively.
considerations relevant to RSVP, used as the signaling protocol
integrated services, are discussed in RFC 2209 [14].

A specific security consideration relevant to providing quality
service over PPP links appears when relying on either observed
theoretical average packet expansion during admission control due
bit- or byte-stuffing. Implementations based on these packet
expansion values contain a potential vulnerability to denial
service attacks. An adversary could intentionally send traffic
will result in worst case bit- or byte stuffing packet expansion
This in turn could result in quality of service guarantees not
met for other flows due to overly permissive admission control.
potential denial of service attack argues strongly for using a
case expansion factor in admission control calculations, even
controlled load service

Beyond the considerations documented above, this document
no new security issues on top of those discussed in the
ISSLL documents [1], [2] and [3] and AVT document [4]. Any use
these service mappings assumes that all requests for service
authenticated appropriately

6.

[1] Bormann, C., "Providing Integrated Services over Low-
Links", RFC 2689, September 1999.

[2] Bormann, C., "The Multi-Class Extension to Multi-Link PPP",
2686, September 1999.

[3] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing",
RFC 2687, September 1999.

[4] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
Low-Speed Serial Links", RFC 2508, February 1999.

[5] Wroclawski, J., "Specification of the Controlled-Load
Element Service", RFC 2211, September 1997.

[6] Partridge, C. and R. Guerin, "Specification of
Quality of Service", RFC 2212, September 1997.

Jackowski, et al. Standards Track [Page 12]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

[7] Shenker, S. and J. Wroclawski, "General
Parameters for Integrated Service Network Elements", RFC 2215,
September 1997.

[8] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links",
RFC 1144, February 1990.

[9] B. Davie et al. "Integrated Services in the Presence
Compressible Flows", Work in Progress (draft-davie-intserv
compress-00.txt), Feb. 1999.

[10] Engan, M., Casner, S. and C. Bormann, "IP Header
over PPP", RFC 2509, February 1999.

[11] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.

[12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T
Coradettim, "The PPP Multilink Protocol (MP)", RFC 1990,
1996.

[13] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
51, RFC 1661, July 1994.

[14] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP
-- Version 1 Message Processing Rules", RFC 2209,
1997.

Jackowski, et al. Standards Track [Page 13]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

7. Authors'

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

Phone: +1 (408) 813 6294
EMail: stevej@DeterministicNetworks.

David
Intel Architecture Labs (IAL
JF3-206-H10
2111 NE 25th
Hillsboro, OR 97124-5961

Phone: +1 (503) 264 4510
EMail: David.Putzolu@intel.

Eric S.
Argon Networks, Inc
25 Porter
Littleton, MA 01460

Phone: +1 (978) 486-0665
EMail: esc@argon.

Bruce
Cisco Systems, Inc
250 Apollo
Chelmsford, MA, 01824

Phone: +1 (978) 244 8921
EMail: bdavie@cisco.

This document draws heavily on the work of the ISSLL WG of the IETF

Jackowski, et al. Standards Track [Page 14]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

Appendix A. Admission Control Considerations for POTS

The protocols used in current implementations of POTS modems
exhibit significant changes in link rate and delay over the
of a connection. Admission control and link scheduling
used with these devices MUST be prepared to compensate for
variability in order to provide a robust implementation of
services

Link rate on POTS modems is typically reported at connection time
This value may change over the duration of the connection. The v.34
protocol, used in most POTS modems, is adaptive to link conditions
and is able to recalibrate transmission rate multiple times over
duration of a connection. Typically this will result in a
(~10%) increase in transmission rate over the initial
within the first minute of a call. It is important to note, however
that other results are possible as well, including decreases
available bandwidth. Admission control algorithms MUST take
changes into consideration as they occur, and implementations MUST
able to gracefully handle the pathological case where link
actually drops below the currently reserved capacity of a link

Delay experienced by traffic over POTS modems can vary
over time. Unlike link rate, the delay often does not converge to
stable value. The v.42 protocol is used in most POTS modems
provide link-layer reliability. This reliability, which
implemented via retransmission, can cause frames to
significant delays. Retransmissions also implicitly steal
bandwidth from other traffic. These delays and reductions in
bandwidth make it extremely difficult to honor a guaranteed
reservation. On a link that is actually lightly or moderately loaded
a controlled load service can to some extent accept such events
part of the behavior of a lightly loaded link. Unfortunately,
actual link utilization increases, v.42 retransmissions have
potential of stealing larger and larger fractions of available
bandwidth; making even controlled load service difficult to offer
high link utilization when retransmissions occur

Jackowski, et al. Standards Track [Page 15]

RFC 2688 Integrated Services Mappings Low Speed Nets September 1999

9. Full Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Jackowski, et al. Standards Track [Page 16]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX