As per Relevance of the word overhead, we have this rfc below:
Network Working Group C.
Request for Comments: 2689 Universitaet Bremen
Category: Informational September 1999
Providing Integrated Services over Low-bitrate
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document describes an architecture for providing
services over low-bitrate links, such as modem lines, ISDN B
channels, and sub-T1 links. It covers only the lower parts of
Internet Multimedia Conferencing Architecture [1];
components required for application services such as
Telephony (e.g., a session initiation protocol) are outside the
of this document. The main components of the architecture are:
real-time encapsulation format for asynchronous and synchronous low
bitrate links, a header compression architecture optimized for real
time flows, elements of negotiation protocols used between
(or between hosts and routers), and announcement protocols used
applications to allow this negotiation to take place
1.
As an extension to the "best-effort" services the Internet is well
known for, additional types of services ("integrated services")
support the transport of real-time multimedia information are
developed for, and deployed in the Internet. Important elements
this development are
- parameters for forwarding mechanisms that are appropriate
real-time information [11, 12],
- a setup protocol that allows establishing special
treatment for real-time information flows (RSVP [4]),
- a transport protocol for real-time information (RTP/RTCP [6]).
Bormann Informational [Page 1]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
In addition to these elements at the network and transport levels
the Internet Multimedia Conferencing Architecture [1],
components are required to define application services such
Internet Telephony, e.g., protocols for session initiation
control. These components are outside the scope of this document
Up to now, the newly developed services could not (or only
inefficiently) be used over forwarding paths that include low-
links such as 14.4, 33.6, and 56 kbit/s modems, 56 and 64 kbit/s
B-channels, or even sub-T1 links. The encapsulation formats used
these links are not appropriate for the simultaneous transport
arbitrary data and real-time information that has to meet
delay requirements. Transmission of a 1500 byte packet on a 28.8
kbit/s modem link makes this link unavailable for the transmission
real-time information for about 400 ms. This adds a worst-case
that causes real-time applications to operate with round-trip
on the order of at least a second -- unacceptable for real-
conversation. In addition, the header overhead associated with
protocol stacks used is prohibitive on low-bitrate links,
compression down to a few dozen bytes per real-time
packet is often desirable. E.g., the overhead of at least 44
(4+20+8+12) bytes for HDLC/PPP, IP, UDP, and RTP
overshadows typical audio payloads such as the 19.75 bytes needed
a G.723.1 ACELP audio frame -- a 14.4 kbit/s link is
consumed by this header overhead alone at 40 real-time frames
second total (i.e., at 25 ms packetization delay for one stream or 50
ms for two streams, with no space left for data, yet). While
header overhead can be reduced by combining several real-
information frames into one packet, this increases the delay
while filling that packet and further detracts from the goal
real-time transfer of multi-media information over the Internet
This document describes an approach for addressing these problems
The main components of the architecture are
- a real-time encapsulation format for asynchronous and
low-bitrate links
- a header compression architecture optimized for real-time flows
- elements of negotiation protocols used between routers (or
hosts and routers),
- announcement protocols used by applications to allow
negotiation to take place
Bormann Informational [Page 2]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
2. Design
The main design goal for an architecture that addresses real-
multimedia flows over low-bitrate links is that of minimizing
end-to-end delay. More specifically, the worst case delay (
removing possible outliers, which are equivalent to packet
from an application point of view) is what determines the
points selected by the applications and thus the delay
perceived by the user
In addition, any such architecture should obviously undertake
attempt to maximize the bandwidth actually available to media data
overheads must be minimized
An important component of the integrated services architecture is
provision of reservations for real-time flows. One of the
that systems on low-bitrate links (routers or hosts) face
performing admission control for such reservations is that they
translate the bandwidth requested in the reservation to the
actually consumed on the link. Methods such as data
and/or header compression can reduce the requirements on the link
but admission control can only make use of the reduced
in its calculations if it has enough information about the
stream to know how effective the compression will be. One goal
the architecture therefore is to provide the integrated
admission control with this information. A beneficial side
may be to allow the systems to perform better compression than
be possible without this information. This may make it worthwhile
provide this information even when it is not intended to make
reservation for a real-time flow
3. The Need for a Concerted
Many technical approaches come to mind for addressing these problems
in particular a new form of low-delay encapsulation to address
and header compression methods to address overhead. This
shows that these techniques should be combined to solve the problem
3.1. Real-Time
The purpose of defining a real-time link-layer encapsulation
is to be able to introduce newly arrived real-time packets into
link-layer data stream without having to wait for the
transmitted (possibly large) packet to end. Obviously, a real-
encapsulation must be part of any complete solution as the problem
delays induced by large frames on the link can only be solved on
layer
Bormann Informational [Page 3]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
To be able to switch to a real-time packet quickly in an
driver, it is first necessary to identify packets that belong
real-time flows. This can be done using a heuristic approach (e.g.,
favor the transmission of highly periodic flows of small
transported in IP/UDP, or use the IP precedence fields in a
way defined within an organization). Preferably, one also could
use of a protocol defined for identifying flows that require
treatment, i.e. RSVP. Of the two service types defined for use
RSVP now, the guaranteed service will only be available in
environments; for this and various other reasons, the service
chosen for many adaptive audio/video applications will most likely
the controlled-load service. Controlled-load does not
control parameters for target delay; thus it does not
identify those packet streams that would benefit most from
transported in a real-time encapsulation format. This calls for
way to provide additional parameters in integrated services
setup protocols to control the real-time encapsulation
Real-time encapsulation is not sufficient on its own, however:
if the relevant flows can be appropriately identified for real-
treatment, most applications simply cannot operate properly on low
bitrate links with the header overhead implied by the combination
HDLC/PPP, IP, UDP, and RTP, i.e. they absolutely require
compression
3.2. Header
Header compression can be performed in a variety of elements and at
variety of levels in the protocol architecture. As many vendors
Internet Telephony products for PCs ship applications, the
that is most obvious to them is to reduce overhead by
header compression at the application level, i.e. above
protocols such as UDP (or actually by using a non-standard
efficiently coded header in the first place).
Generally, header compression operates by installing state at
ends of a path that allows the receiving end to
information omitted at the sending end. Many good techniques
header compression (RFC 1144, [2]) operate on the assumption that
path will not reorder the frames generated. This assumption does
hold for end-to-end compression; therefore additional overhead
required for resequencing state changes and for compressed
making use of these state changes
Assume that a very good application level header compression
for RTP flows could be able to save 11 out of the 12 bytes of an
header [3]. Even this perfect solution only reduces the total
overhead by 1/4. It would have to be deployed in all applications
Bormann Informational [Page 4]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
even those that operate on systems that are attached to higher
bitrate links
Because of this limited effectiveness, the AVT group that
responsible for RTP within the IETF has decided to not further
application level header compression
For router and IP stack vendors, the obvious approach is to
header compression that can be negotiated between peer routers
Advanced header compression techniques now being defined in the
[2] certainly can relieve the link from significant parts of
IP/UDP overhead (i.e., most of 28 of the 44 bytes mentioned above).
One of the design principles of the new IP header
developed in conjunction with IPv6 is that it stops at layers
semantics of which cannot be inferred from information in lower
(outer) headers. Therefore, this header compression technique
cannot compress the data that is contained within UDP packets
Any additional header compression technique runs into a problem:
it assumes specific application semantics (i.e., those of RTP and
payload data format) based on heuristics, it runs the risk of
triggered falsely and (e.g. in case of packet loss)
packets that are catastrophically incorrect for the
actually being used. A header compression technique that can
operated based on heuristics but does not cause
decompression even if the heuristics failed is described in [7];
companion document describes the mapping of this technique to
[10].
With all of these techniques, the total IP/UDP/RTP header
for an audio stream can be reduced to two bytes per packet.
technology need only be deployed at bottleneck links; high-
links can transfer the real-time streams without routers or
expending CPU cycles to perform header compression
4. Principles of Real-Time Encapsulation for Low-Bitrate
The main design goal for a real-time encapsulation is to minimize
delay incurred by real-time packets that become available for
while a long data packet is being sent. To achieve this,
encapsulation must be able to either abort or suspend the transfer
the long data packet. As an additional goal is to minimize
overhead required for the transmission of packets from
flows, this strongly argues for being able to suspend a packet, i.e
segment it into parts between which the real-time packets can
transferred
Bormann Informational [Page 5]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
4.1. Using existing IP
Transmitting only part of a packet, to allow higher-priority
to intervene and then resuming its transmission later on, is a
of fragmentation. Fragmentation is an existing functionality of
IP layer: An IPv4 header already contains fields that allow a
IP datagram to be fragmented into small parts. A sender's "real-
PPP" implementation might simply indicate a small MTU to its IP
and thus cause all larger datagrams to be fragmented down to a
that allows the access delay goals to be met (this assumes that
IP stack is able to priority-tag fragments, or that the
implementation is able to correlate the fragments to the initial
that carries the information relevant for prioritizing, or that
initial fragments can be high-priority). (Also, a PPP
can negotiate down the MTU of its peer, causing the peer to
to a small size, which might be considered a crude form
negotiating an access delay goal with the peer system -- if
system supports priority queueing at the fragment level.)
Unfortunately, a full, 20 byte IP header is needed for each
(larger when IP options are used). This limits the minimum size
fragments that can be used without too much overhead. (Also,
size of non-final fragments must be a multiple of 8 bytes,
limiting the choice.) With path MTU discovery, IP
fragmentation causes TCP implementations to use small MSSs --
further increases the per-packet overhead to 40 bytes per fragment
In any case, fragmentation at the IP level persists on the
further down to the datagram receiver, increasing the
overheads and router load throughout the network. With its
overhead and the adverse effect on the Internet, IP
fragmentation can only be a stop-gap mechanism when no
fragmentation protocol is available in the peer implementation
4.2. Link-Layer
Cell-oriented multiplexing techniques such as ATM that
regular points where cells from a different packet can
interpolated are too inefficient for low-bitrate links; also,
are not supported by chips used to support the link layer in low
bitrate routers and host interfaces
Bormann Informational [Page 6]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
Instead, the real-time encapsulation should as far as possible
use of the capabilities of the chips that have been deployed.
synchronous lines, these chips support HDLC framing; on
lines, an asynchronous variant of HDLC that usually is implemented
software is being used. Both variants of HDLC provide a
mechanism to indicate the end of a frame over the link. The
solution to the segmentation problem is to combine this
with an indication of whether the delimiter terminates or
the current packet
This indication could be in an octet appended to each
information field; however, seven out of eight bits of the
would be wasted. Instead, the bit could be carried at the start
the next frame in conjunction with multiplexing information (
protocol identifier etc.) that will be required here anyway.
the real-time flows will in general be periodic, this
information could convey (part of) the compressed form of the
for the packet. If packets from the real-time flow generally are
constant length (or have a defined maximum length that is
used), the continuation of the suspended packet could be
attached to it, without expending a further frame delimiter, i.e.,
the interpolation of the real-time packet would then have
overhead. Since packets from low-delay real-time flows
will not require the ability to be further suspended,
continuation bit could be reserved for the non-real-time
stream
One real-time encapsulation format with these (and other)
is described in ITU-T H.223 [13], the multiplex used by the H.324
modem-based videophone standard [14]. It was investigated
compatibility could be achieved with this specification, which
be used in future videophone-enabled (H.324 capable) modems
However, since the multiplexing capabilities of H.223 are limited
15 schedules (definitions of sequences of packet types that can
identified in a multiplex header), for general Internet usage
superset or a more general encapsulation would have been required
Also, a PPP-style negotiation protocol was needed instead of
(and necessarily extending) ITU-T H.245 [15] for setting
parameters of the multiplex. In the PPP context, the
with the encapsulations for data compression and link
encryption needed to be defined (including operation in the
of padding). But most important, H.223 requires synchronous
chips that can be configured to send frames without an attached CRC
which is not possible with all chips deployed in
available routers; so complete compatibility was unachievable
Bormann Informational [Page 7]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
Instead of adopting H.223, it was decided to pursue an approach
is oriented towards compatibility both with existing hardware
existing software (in particular PPP) implementations. The
subsection groups these implementations according to
capabilities
4.3. Implementation
This section introduces a number of terms for types
implementations that are likely to emerge. It is important to
these different implementation models in mind as there is no
approach that fits all models best
4.3.1. Sender
There are two fundamental approaches to real-time transmission
low-bitrate links
Sender type 1
The PPP real-time framing implementation is able to control
transmission of each byte being transmitted with some known
bounded delay (e.g., due to FIFOs). For example, this
generally true of PC host implementations, which directly
serial interface chips byte by byte or by filling a very
FIFO. For type 1 senders, a suspend/resume type approach will
typically used: When a long frame is to be sent, the attempt is
send it undivided; only if higher priority packets come up
the transmission will the lower-priority long frame be
and later resumed. This approach allows the minimum variation
access delay for high-priority packets; also,
overhead is only incurred when actually needed
Sender type 2
With type 2 senders, the interface between the PPP real-
framing implementation and the transmission hardware is not
terms of streams of bytes, but in terms of frames, e.g., in
form of multiple (prioritized) send queues directly supported
hardware. This is often true of router systems for
links, in particular those that have to support a large number
low-bitrate links. As type 2 senders have no way to suspend
frame once it has been handed down for transmission,
typically will use a queues-of-fragments approach, where
packets are always split into units that are small enough
maintain the access delay goals for higher-priority traffic
There is a trade-off between the variation in access
resulting from a large fragment size and the overhead that
incurred for every long packet by choosing a small fragment size
Bormann Informational [Page 8]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
4.3.2. Receiver
Although the actual work of formulating transmission streams
real-time applications is performed at the sender, the ability of
receiver to immediately make use of the information received
on its characteristics
Receiver type 1
Type 1 receivers have full control over the stream of
received within PPP frames, i.e., bytes received are
immediately to the PPP real-time framing implementation (with
known, bounded delay e.g. due to FIFOs etc.).
Receiver type 2
With type 2 receivers, the PPP real-time framing
only gets hold of a frame when it has been received completely
i.e., the final flag has been processed (typically by some
chip that directly fills a memory buffer).
4.4.
As a result of the diversity in capabilities of
implementations, there are now two specifications for real-
encapsulation: One, the multi-class extension to the PPP multi-
protocol, is providing the solution for the queues-of-
approach by extending the single-stream PPP multi-link protocol
multiple classes [8]. The other encapsulation, PPP in a real-
oriented HDLC-like framing, builds on this specification end
it by a way to dynamically delimit multiple fragments within one
frame [9], providing the solution for the suspend/resume
approach
5. Principles of Header Compression for Real-Time
A good baseline for a discussion about header compression is in
new IP header compression specification that was designed
conjunction with the development of IPv6 [2]. The techniques
there can reduce the 28 bytes of IPv4/UDP header to about 6
(depending on the number of concurrent streams); with the remaining 4
bytes of HDLC/PPP overhead and 12 bytes for RTP the total
overhead can be about halved but still exceeds the size of a G.723.1
ACELP frame. Note that, in contrast to IP header compression,
environment discussed here assumes the existence of a full-duplex
link and thus can rely on negotiation where IP header
requires repeated transmission of the same information. (The use
the architecture of the present document with link layer
has not yet been examined.)
Bormann Informational [Page 9]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
Additional design effort was required for RTP header compression
Applying the concepts of IP header compression, of the (at least) 12
bytes in an RTP header, 7 bytes (timestamp, sequence, and marker bit
would qualify as RANDOM; DELTA encoding cannot generally be
without further information since the lower layer header does
unambiguously identify the semantics and there is no TCP
that can be relied on to detect incorrect decompression. Only a
semantics-oriented approach can provide better compression (just
RFC 1144 can provide very good compression of TCP headers by
use of semantic knowledge of TCP and its checksumming method).
For RTP packets, differential encoding of the sequence number
timestamps is an efficient approach for certain cases of payload
formats. E.g., speech flows generally have sequence numbers
timestamp fields that increase by 1 and by the frame size
timestamp units, resp.; the CRTP (compressed RTP) specification
use of this relationship by encoding these fields only when
second order difference is non-zero [7].
6. Announcement Protocols Used by
As argued, the compressor can operate best if it can make use
information that clearly identifies real-time streams and
information about the payload data format in use
If these systems are routers, this consent must be installed
router state; if these systems are hosts, it must be known to
networking kernels. Sources of real-time information flows
already describing characteristics of these flows to their
and to the routers in the form of TSpecs in RSVP PATH messages [4].
Since these messages make use of the router alert option, they
seen by all routers on the path; path state about the packet
is normally installed at each of these routers that implement RSVP
Additional RSVP objects could be defined that are included in
messages by those applications that desire good performance over low
bitrate links; these objects would be coded to be ignored by
that are not interested in them (class number 11bbbbbb as defined
[4], section 3.10).
Note that the path state is available in the routers even when
reservation is made; this allows informed compression of best-
traffic. It is not quite clear, though, how path state could be
down quickly when a source ceases to transmit
Bormann Informational [Page 10]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
7. Elements of Hop-By-Hop Negotiation
The IP header compression specification attempts to account
simplex and multicast links by providing information about
compressed streams only in the forward direction. E.g., a
IP/UDP header must be sent after F_MAX_TIME (currently 3 seconds),
which is a negligible total overhead (e.g. one full header every 150
G.723.1 packets), but must be considered carefully in scheduling
real-time transmissions. Both simplex and multicast links are
prevailing in the low-bitrate environment (although
functionality may become more important with wireless systems);
this document, we therefore assume full-duplex capability
As compression techniques will improve, a negotiation between the
peers on the link would provide the best flexibility
implementation complexity and potential for extensibility. The
routers/hosts can decide which real-time packet streams are to
compressed, which header fields are not to be sent at all,
multiplexing information should be used on the link, and how
remaining header fields should be encoded. PPP, a well-tried
of negotiation protocols, is already used on most of the low-
links and seems to provide the obvious approach. Cooperation
PPP is also needed to negotiate the use of real-time
between systems that are not configured to automatically do so
Therefore, PPP options that can be negotiated at the link setup (LCP
phase are included in [8], [9], and [10].
8. Security
Header compression protocols that make use of assumptions
application protocols need to be carefully analyzed whether it
possible to subvert other applications by maliciously
inadvertently enabling their use
It is generally not possible to do significant hop-by-hop
compression on encrypted streams. With certain security policies,
may be possible to run an encrypted tunnel to a network access
that does header compression on the decapsulated packets and
them over an encrypted link encapsulation; see also the short
of interactions between real-time encapsulation and encryption
section 4 above. If the security requirements permit, a special
payload data format that encrypts only the data may preferably
used
Bormann Informational [Page 11]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
9.
[1] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "
Internet Multimedia Conferencing Architecture", Work
Progress
[2] Degermark, M., Nordgren, B. and S. Pink, "IP
Compression", RFC 2507, February 1999.
[3] Scott Petrack, Ed Ellesson, "Framework for C/RTP:
RTP Using Adaptive Differential Header Compression",
contribution to the mailing list rem-conf@es.net,
1996.
[4] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin
"Resource ReSerVation Protocol (RSVP) -- Version 1
Specification", RFC 2205, September 1997.
[5] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
1996.
[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson
"RTP: A Transport Protocol for Real-Time Applications",
1889, January 1996.
[7] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
Low-Speed Serial Links", RFC 2508, February 1999.
[8] Bormann, C., "The Multi-Class Extension to Multi-Link PPP",
2686, September 1999.
[9] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing",
RFC 2687, September 1999.
[10] Engan, M., Casner, S. and C. Bormann, "IP Header
over PPP", RFC 2509, February 1999.
[11] Wroclawski, J., "Specification of the Controlled-Load
Element Service", RFC 2211, September 1997.
[12] Shenker, S., Partridge, C. and R. Guerin. "Specification
Guaranteed Quality of Service", RFC 2212, September 1997.
Bormann Informational [Page 12]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
[13] ITU-T Recommendation H.223, "Multiplexing protocol for low
rate multimedia communication", International
Union, Telecommunication Standardization Sector (ITU-T),
1996.
[14] ITU-T Recommendation H.324, "Terminal for low bit
multimedia communication", International
Union, Telecommunication Standardization Sector (ITU-T),
1996.
[15] ITU-T Recommendation H.245, "Control protocol for
communication", International Telecommunication Union
Telecommunication Standardization Sector (ITU-T), March 1996.
10. Author's
Carsten
Universitaet Bremen FB3
Postfach 330440
D-28334 Bremen,
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.
Much of the early discussion that led to this document was done
Scott Petrack and Cary Fitzgerald. Steve Casner, Mikael Degermark
Steve Jackowski, Dave Oran, the other members of the ISSLL
on low bitrate links (ISSLOW), and in particular the ISSLL WG co
chairs Eric Crawley and John Wroclawski have helped in making
architecture a reality
Bormann Informational [Page 13]
RFC 2689 Integrated Services over Low-bitrate Links September 1999
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
Bormann Informational [Page 14]
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
