home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_i
/
draft-ietf-issll-isslow-mcml-00.txt
< prev
next >
Wrap
Text File
|
1996-09-23
|
44KB
|
1,044 lines
INTERNET-DRAFT Carsten Bormann
Expires: March 1997 Universitaet Bremen
September 1996
The Multi-Class Extension to Multi-Link PPP
draft-ietf-issll-isslow-mcml-00.txt
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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
Abstract
A companion document describes an architecture for providing
integrated services over low-bitrate links, such as modem lines, ISDN
B-channels, and sub-T1 links [1]. The main components of the
architecture are: a 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 routers (or between hosts and routers), and announcement
protocols used by applications to allow this negotiation to take
place.
This document proposes the solution for the real-time encapsulation
format part of the architecture. The general approach is to start
from the PPP Multilink fragmentation protocol [2] and provide a small
number of extensions to add functionality and reduce the overhead.
This document is a product of the IETF ISSLL working group. It is
also a submission to the IETF PPPEXT working group.
Comments are solicited and should be addressed to the two working
groups' mailing lists at issll@mercury.lcs.mit.edu and ietf-
ppp@merit.edu and/or the author.
Bormann [Page 1]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
1. Introduction
As an extension to the ``best-effort'' services the Internet is well-
known for, additional types of services (``integrated services'')
that support the transport of real-time multimedia information are
being developed for and deployed in the Internet.
A companion document describes an architecture for providing
integrated services over low-bitrate links, such as modem lines, ISDN
B-channels, and sub-T1 links [1]. The main components of the
architecture are: a 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 routers (or between hosts and routers), and announcement
protocols used by applications to allow this negotiation to take
place.
The present document defines the real-time encapsulation format part
of the architecture. As described in more detail in the architecture
document, such a format is required as, e.g., a 1500 byte packet on a
28.8 kbit/s modem link makes this link unavailable for the
transmission of real-time information for about 400 ms. This adds a
worst-case delay that causes real-time applications to operate with
round-trip delays on the order of at least a second -- unacceptable
for real-time conversation.
2. Requirements
The main design goal for the components of an architecture that
addresses real-time multimedia flows over low-bitrate links is that
of minimizing the end-to-end delay. More specifically, the worst
case delay (after removing possible outliers, which are equivalent to
packet losses from an application point of view) is what determines
the playout points selected by the applications and thus the delay
actually perceived by the user.
In addition, every attempt should obviously be undertaken to maximize
the bandwidth actually available to media data; overheads must be
minimized.
The solution should not place unnecessary burdens on the non-real-
time flows. In particular, the usual MTU should be available to
these flows.
The most general approach would provide the ability to suspend any
packet (real-time or not) for a more urgent real-time packet, up to
an infinite number of levels of nesting. On the other hand, it is
likely that there would rarely be a requirement for a real-time
packet to suspend another real-time packet that is not at least about
twice as long. Typically, the largest packet size to be expected on
a PPP link is the default MTU of 1500 bytes. The smallest high-
Bormann [Page 2]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
priority packets are likely to have on the order of 21 bytes
(compressed RTP/G.723.1 packets). In the 1:72 range of packet sizes
to be expected, this translates to a maximum requirement of about
eight levels of suspension (including one level where long real-time
packets suspend long non-real-time packets). On 28.8kbit/s modems,
there seems to be a practical requirement for at least two levels of
suspension (i.e., audio suspends any longer packet including video,
video suspends other very long packets).
An on architectural level, there are several additional requirements
for the fragmentation scheme:
a) The scheme must be predictable enough that admission control can
make decisions based on its characteristics. As is argued in
[1], this will often only be the case when additional hints
about the characteristics of the flow itself are available
(application hints).
b) The scheme must be robust against errors, at least with the same
level of error detection as PPP.
c) The scheme must in general cooperate nicely with PPP. In
particular, it should be as compatible to existing PPP standards
as possible. On a link that (based on PPP negotiation) makes
use of the scheme, it should always be possible to fall back to
standard LCP without ambiguity.
d) The scheme must work well with existing chips and router
systems. For synchronous links this means using HDLC framing;
with much existing hardware, it is also hard to switch off the
HDLC per-frame CRC. For asynchronous links, there is much more
freedom in design; on the other hand, a design that treats them
much different from asynchronous links would lose a number of
desirable properties of PPP.
e) The scheme must be future proof. In particular, the emergence
of V.80 based modems may significantly change the way PPP is
used with modems.
The current draft does not address additional requirements that may
be relevant in conjunction with Frame Relay; however, there seems to
be little problem in applying the principles of this draft to ``PPP
in Frame Relay'' [3].
3. Implementation models
This section introduces a number of terms for types of
implementations that are likely to emerge. It is important to have
these different implementation models in mind as there is no single
approach that fits all models best.
Bormann [Page 3]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
3.1. Sender types
There are two fundamental approaches to real-time transmission on
low-bitrate links:
Sender type 1
The PPP real-time framing implementation is able to control the
transmission of each byte being transmitted with some known,
bounded delay (e.g., due to FIFOs). For example, this is
generally true of PC host implementations, which directly access
serial interface chips byte by byte or by filling a very small
FIFO. For type 1 senders, a suspend/resume type approach will
be typically used: When a long frame is to be sent, the attempt
is to send it undivided; only if higher priority packets come up
during the transmission will the lower-priority long frame be
suspended and later resumed. This approach allows the minimum
variation in access delay for high-priority packets; also,
fragmentation overhead is only incurred when actually needed.
Sender type 2
With type 2 senders, the interface between the PPP real-time
framing implementation and the transmission hardware is not in
terms of streams of bytes, but in terms of frames, e.g., in the
form of multiple (prioritized) send queues directly supported by
hardware. This is often true of router systems for synchronous
links, in particular those that have to support a large number
of low-bitrate links. As type 2 senders have no way to suspend
a frame once it has been handed down for transmission, they
typically will use a queues-of-fragments approach, where long
packets are always split into units that are small enough to
maintain the access delay goals for higher-priority traffic.
There is a trade-off between the variation in access delay
resulting from a large fragment size and the overhead that is
incurred for every long packet by choosing a small fragment
size.
3.2. Receiver types
Although the actual work of formulating transmission streams for
real-time applications is performed at the sender, the ability of the
receiver to immediately make use of the information received depends
on its characteristics:
Receiver type 1
Type 1 receivers have full control over the stream of bytes
received within PPP frames, i.e., bytes received are available
immediately to the PPP real-time framing implementation (with
some known, bounded delay e.g. due to FIFOs etc.).
Receiver type 2
With type 2 receivers, the PPP real-time framing implementation
only gets hold of a frame when it has been received completely,
i.e., the final flag has been processed (typically by some HDLC
Bormann [Page 4]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
chip that directly fills a memory buffer).
4. Using existing mechanisms
Suspending the transmission of packets and resuming their
transmission later on is a kind of fragmentation. Fragmentation is
existing functionality of the IP layer. As fragmentation and
reassembly also are useful in a logical link composed of multiple
physical links, PPP Multilink (a standards track protocol) already
defines a fragmentation mechanism [2]. Unfortunately, neither
approach, as is, fulfills all the requirements listed above.
4.1. Using IP fragmentation
An IPv4 header already contains fields that allow a large IP datagram
to be fragmented into small parts. A queues-of-fragments type sender
might simply indicate a small MTU to its IP stack and thus cause all
larger datagrams to be fragmented down to a size that allows the
access delay goals to be met[1]. (Also, a PPP implementation can
negotiate down the MTU of its peer, causing the peer to fragment to a
small size, which might be considered a crude form of negotiating an
access delay goal with the peer system -- if that system supports
priority queueing at the fragment level.)
Unfortunately, a full, 20 byte IP header is needed for each fragment
(larger when IP options are used). This limits the minimum size of
fragment that can be used without too much overhead. (Also, the size
of non-final fragments must be a multiple of 8, further limiting the
choice.) With path MTU discovery, IP level fragmentation causes TCP
implementations to use small MSSs -- this further increases the per-
packet overhead to 40 bytes per fragment.
In any case, fragmentation at the IP level persists on the path
further down to the datagram receiver, increasing the transmission
overheads and router load throughout the network. With its high
overhead and the adverse effect on the Internet, IP level
fragmentation can only be a stop-gap mechanism when no other
fragmentation protocol is available in the peer implementation.
4.2. Using PPP Multilink as-is
The PPP Multilink Protocol (MP) provides for sequence numbering and
begin/end bits, allowing packets to be split into fragments.
_________________________
[1] This assumes that the IP stack is able to priority-tag frag-
ments, or that the PPP implementation is able to correlate the
fragments to the initial one that carries the information relevant
for prioritizing, or that only initial fragments can be high-
priority.
Bormann [Page 5]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
Figure 1: Multilink Short Sequence Number Fragment Format [2]
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
(Note that the address, control, and most significant PID bytes are
often negotiated to be compressed away.)
MP's monotonically increasing sequence numbering (contiguous numbers
are needed for all fragments of a packet) does not allow to suspend
sending a sequence of fragments of one packet for sending another
packet. It is, however, possible to send intervening packets that
are not encapsulated in multilink headers; thus, MP supports two
levels of priority.
The multilink-as-is approach can be built using existing standards;
multilink capability is now widely deployed and only the sending side
needs to be aware that they are using this for giving priority to
real-time packets.
4.3. Limitations of multilink as-is
Multilink-as-is is not the ideal solution for a number of reasons.
First, because of the single monotonically increasing serial number,
there is only one level of suspension: ``Big'' packets that are sent
via multilink can be suspended by ``small'' packets sent outside of
multilink; the latter are not suspendable.
Second, the ``end'' bit is in the multilink header, which is the
wrong place for suspend/resume type senders. To make a big packet
suspendable, it must be sent with the ``end'' bit off, and (unless
the packet was suspended a small number of bytes before its end) an
empty fragment has to be sent afterwards to ``close'' the packet.
The minimum overhead for sending a suspendable packet thus is twice
the multilink header size (six bytes, including a compressed
multilink protocol field) plus one PPP framing (three bytes). Each
suspension costs another six bytes (not counting the overhead of the
framing for the intervening packet).
Bormann [Page 6]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
Third, the multi-link header is relatively large; as delay bounds
become small (for queues-of-fragments type implementations) or the
frequency of small high-priority packets increases (for
suspend/resume type implementations), the overhead may become
significant.
The general approach of this document is to start from PPP Multilink
and provide a number of extensions to add functionality and reduce
the overhead of using PPP Multilink for real-time transmission.
5. Extending PPP Multilink to multiple classes
The obvious approach to providing more than one level of suspension
with PPP Multilink is to run Multilink multiple times over one link.
Multilink as it is defined provides no way for more than one instance
to be active. Fortunately, a number of bits are unused in the
Multilink header: two bits in the short sequence number format (as
can be seen in Figure 1), six in the long sequence number format.
This document defines (some of the) previously unused bits as a class
number:
Figure 2: Short Sequence Number Fragment Format With Classes
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|E|cls| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
Each class runs a separate copy of the mechanism defined in [2], i.e.
uses a separate sequence number space and reassembly buffer.
Similarly, for the long sequence number format:
Bormann [Page 7]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
Figure 3: Long Sequence Number Fragment Format With Classes
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-+-+-+-+---------------+
MP Header: |B|E| class |0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+
| sequence number (L) |
+---------------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
Together with the ability to send packets without a multilink header,
this provides four levels of suspension with 12-bit headers (probably
sufficient for many practical applications) and sixteen levels with
24-bit headers (only four of the six free bits are used in this case
-- based on the rationale given above, sixteen levels should
generally be more than sufficient).
6. Sending the final bit at the end of the packet
As explained above, having the ``end'' bit within the packet header
causes additional overhead with suspend/resume type senders. This
section defines an alternative way to convey the end bit that allows
deferring the decision whether the fragment is final or needs to be
suspended to the point in time when the fragment is ended.
In this scheme, the value of the end bit is contained in the last
byte of each frame information field. If the byte has the value
SUSPEND (0xC3), the end bit is zero (i.e., the fragment is not the
last one of the packet); the byte is NOT part of the data of the
packet. If the byte has the value END (0xDE), the end bit is one
(i.e., this is the last fragment of the packet); the byte is NOT part
of the data of the packet. If the byte has any other value, the end
bit is one (i.e., this is the last fragment of the packet); the byte
IS part of the data of the fragment. (Assuming an equal distribution
of final bytes[2], the average overhead of this scheme for non-
_________________________
[2] Actually, the distribution is not at all equal: In a trace
of slightly more than a million packets on a busy Ethernet, the
values 0xDE and 0xC3 both occurred only 244 times as the last byte
of a packet. Obviously, the distribution will not be as unequal
when data compression and/or encryption are in use.
Bormann [Page 8]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
suspended frames is 1/128 byte; the overhead for suspended frames is
exactly 1 byte.)
As the end bit is then no longer required in the header, the free bit
can be used as an additional bit for the class number in the short
sequence number fragment format:
Figure 4: Short Sequence Number Fragment Format With Classes and
Trailing End Bit
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|class| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
| ................+
| . SSP/TRM (opt) :
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
For the long sequence number fragment format, the freed bit is sent
as zero.
7. Prefix elision: Compressing common header bytes
For some applications, all packets of a certain class will have a
common protocol identifier (or even more than one common prefix
byte). In this case, the following optimization is possible: the
class number can be associated with a prefix of bytes that are
removed from each packet before transmission and that are implicitly
prepended to the reassembled packet after reception.
Note that if only some of the packets to be transmitted at a certain
level of priority have the common prefix, it may still be possible to
utilize this method by allocating two class numbers and only
associating one of them with the prefix. (This is the reason four of
the unused bits in the long sequence number format have been
allocated to the class number instead of the three that generally
should suffice.)
Prefix elision is not a replacement for header compression or data
compression: it allows to compress away prefixes that often are not
reachable by these other methods.
Bormann [Page 9]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
8. The compact fragment format
This section describes an optional multilink fragment format that is
more optimized towards single-link operation and frequent suspension
(type 1)/a small fragment size (type 2). This format has been
designed to retain the overall HDLC based format of frames, so that
existing synchronous HDLC chips and async to sync converters can be
used on the link. If the design can be optimized for async only
operation, more design alternatives are available [4]; with the
advent of V.80 style modems, asynchronous communications may decrease
in importance, though.
When operating over a single link, the Multilink sequence number is
used only for loss detection. Even a 12-bit sequence number clearly
is larger than required for this application on most kinds of links.
We therefore define a third, compact multilink header format option.
As, with a compact header, we can expect all packets to be sent over
the multilink, we can provide an additional compression mechanism for
this format: the MP protocol identifier is not sent with the compact
fragment header. This obviously requires prior negotiation (similar
to the way address and control field compression are negotiated), as
well as avoiding the bit combination 0xFF, as the start of a new LCP
negotiation could otherwise not be reliably detected.
9. Normal header:
Figure 5: Compact Fragment Format (Normal Header).
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+...............................+
: SUSPEND/TERMINATE :
+---+---+---+---+---+---+---+---+
| Frame |
| CRC |
+---+---+---+---+---+---+---+---+
Having the last bit always be 1 helps with HDLC chips that operate
specially on least significant bits in HDLC addresses.
The R bit is the inverted equivalent of the B bit in the other
fragment formats, i.e. R = 1 means that this fragment resumes a
packet previous fragments of which have been sent already.
The following trick avoids the case of a header byte of 0xFF: For
class 7, the R bit can never be one. This means that class 7 frames
Bormann [Page 10]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
cannot be suspended/resumed. (This is also the reason the sense of
the B bit is inverted to an R bit in the compact fragment format.)
[[[The sequence number is not particularly useful with class 7 and
could be used to distinguish eight more classes -- this would add
complexity but also increase the usefulness of prefix elision. The
author currently does not see a strong requirement for this.]]]
10. Insertion header:
In many cases, when a frame is suspended, a very short frame is
interspersed and the suspended frame is then immediately continued.
In certain cases, it may be beneficial to further reduce the overhead
associated with this by removing the intermediate flag(s) and
replacing the 16-bit (or larger) CRC by a smaller CRC.
If the compact fragment format with insertion headers is negotiated,
a frame in the compact fragment format can start with the content of
one or more short packets, called ``insertions''. Each of these
packets is protected by an 8-bit CRC, computed over the insertion
header byte and the data part sent in the insertion. At the end of
the insertion, no flag is sent, but another (insertion or normal)
header follows immediately. The frame finally ends in a normal
header, data for this header, and a frame CRC that covers the entire
of all inserted and normal packets. Alternatively, the frame can
simply be ended after an inserted packet by sending the frame CRC and
terminating flag(s).
Figure 6: Compact Fragment Format (Insertion Header).
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| length L | C | 0 |
+---+---+---+---+---+---+---+---+
: :
: Inserted packet :
: (length L) :
: :
+---+---+---+---+---+---+---+---+
| 8-bit CRC |
+---+---+---+---+---+---+---+---+
| next header |
: (insertion or normal) :
: (possibly repeated) :
+---+---+---+---+---+---+---+---+
| Frame CRC (covering all |
| all data between the flags) |
+---+---+---+---+---+---+---+---+
The class number of a packet in the insertion is computed from the C-
bit as ``class = C + 8'', i.e., we reserve classes 8 and 9 for
inserted packets. As an example, one could use class number 8 for
compressed RTP (saving one or two additional bytes with prefix
Bormann [Page 11]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
elision) and 9 for any other packet type. (Note that, as with class
7, classes 8 and 9 cannot be suspended, as there is no way to
indicate suspension or resumption.)
Since not all serial hardware can immediately deliver initial parts
of frames that have not yet completely arrived (see ``type 2
receivers'' in section 3 above), the use of the insertion header may
be counter-productive in achieving latency goals; it therefore can be
negotiated separately from the use of the normal compact header..
Also, because the initial byte of the HDLC frame has a zero LSB, this
format may not be applicable if chips are used that do strange things
with the last bit of address field bytes.
Implementation note: A sender should not send too many insertions
before a normal header fragment in one frame, as the overall
reliability of the actual data part of the frame (as indicated by the
frame CRC) suffers.
11. Negotiable options
The following options are already defined by MP:
o Multilink Maximum Received Reconstructed Unit
o Multilink Short Sequence Number Header Format
o Endpoint Discriminator
11.1. Multilink header format option
A summary of the Multilink Header Format Option format is shown
below. The fields are transmitted from left to right.
Figure 7:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 3 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This option advises the peer that the implementation wishes to
receive fragments with a format given by the code number. By
default, long sequence number multilink headers without classes and
the end bit in the header are used. When this option is received, an
implementation MUST either transmit all subsequent multilink packets
on all links of the bundle with the multilink header format given or
configure-NAK or configure-Reject the option.
Bormann [Page 12]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
The value defined for code are:
- 0 or option not present: long sequence number fragment format
- 2: long sequence number fragment format with classes
- 3: long sequence number fragment format with classes and
trailing end bit
- 4 or Short Sequence Number Header Format Option (type 18)
present: short sequence number fragment format
- 6: short sequence number fragment format with classes
- 7: short sequence number fragment format with classes and
trailing end bit
- 11: compact fragment format (always with classes and trailing
end bit) with normal header only
- 15: compact fragment format (always with classes and trailing
end bit) with normal and insertion headers
[[[Note for further discussion: The number of alternatives is too
large. The variations possible should be restricted to have a good
chance that two peer implementations have one option in common.]]]
11.2. Prefix elision option
This option advises the peer that the implementation wishes to send
only packets with a certain prefix in each of the given classes; the
prefix is not sent as part of the information in the fragment(s) of
this class. By default, this common prefix is empty for all classes.
When this option is received, an implementation MUST either add the
prefix given for the class to all subsequently received multilink
packets of each of the given classes on all links of the bundle or
configure-NAK or configure-Reject the option.
If one of the formats with classes has not been negotiated, class 0
is used to indicate a common prefix for all packets sent within
multilink fragments.
Figure 8:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Option Length | Class | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix...
+-+-+-+-+-+-+-+-+
Bormann [Page 13]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
Note that the sense of this option is an indication from the sender
to the receiver, unlike most PPP options that indicate capabilities
of the receiver to the sender.
12. Acknowledgements
David Oran suggested using PPP Multilink for real-time framing and
reminded the author of his earlier attempts of making Multilink more
useful for this purpose. The participants in a lunch BOF at the
Montreal IETF gave useful input on the design tradeoffs in various
environments.
13. References
[1] C. Bormann, Providing integrated services over low-bitrate
links, work in progress (draft-ietf-issll-isslow-00.txt), June
1996.
[2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The
PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes
RFC1717).
[3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996.
[4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'',
September 20, 1996, Work in Progress (draft-andrades-framing-
ext-00.txt).
14. Addresses
14.1. Working Group
The ISSLL working group can be contacted via the co-chairs, Eric
Crawley <esc@baynetworks.com> and John Wroclawski <jtw@lcs.mit.edu>,
or via its WG mailing list <issll@mercury.lcs.mit.edu>.
14.2. Author's address
Carsten Bormann
Universitaet Bremen FB3 TZI
Postfach 330440
D-28334 Bremen, GERMANY
cabo@informatik.uni-bremen.de
phone +49.421.218-7024
Bormann [Page 14]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
A. Benchmarks
For the following considerations, we will define the ``normal'' PPP
header overhead to be four bytes: one byte of protocol identifier
(assuming address and control field compression as well as the use of
protocols that have protocol identifiers that can be compressed to
one byte), two bytes of CRC and one byte of flag. These assumptions
are not entirely accurate, as the protocol identifier and the CRC are
subject to bit- or octet-stuffing, slightly increasing the overhead.
In addition, many of the synchronous serial chips used today cannot
easily output frames that are delimited by only a single flag byte.
Just sending two packets sequentially using standard encapsulation
thus costs 8 bytes:
Pid1 . . . 2*CRC Flag Pid2 . . . 2*CRC Flag
Basic 12-bit multilink adds 3 bytes of header overhead to each
packet, as well as six bytes (the same three bytes plus four bytes
normal PPP overhead, minus the protocol identifier) to each
additional fragment.
MPPid 2*MPH Pid . . . 2*CRC Flag
Pid . . . 2*CRC Flag
MPPid 2*MPH . . . 2*CRC Flag
Being able to insert a real-time frame into a long packet
encapsulated in basic multilink therefore requires 9 more bytes of
overhead than just sending the two packets sequentially using
standard encapsulation. The six-byte overhead will generally recur
for longer packets, as the final bit is in the packet header and thus
at least one additional fragment (zero length, just to carry the
final bit) is required.
12-bit multilink with classes does not change the overhead at the top
level of priorities, unless the header prefix option is used and is
useful (i.e., only a small number of PPP protocol identifiers is in
use). In that case, 1 byte of overhead is saved per low-priority
packet.
The compact header reduces the additional per-packet overhead to 1
byte (or 0 bytes if the header prefix option is effective). The
total additional overhead for the insertion of a real-time frame thus
is only 6 to 4 bytes, if the special insertion header cannot be used.
NH [Pid] . . . 2*CRC Flag
NH [Pid] . . . 2*CRC Flag
NH . . . 2*CRC Flag
If the insertion header can be used, the additional overhead is
reduced by two more bytes, i.e., 4 to 2 bytes (of which one is the
block check byte).
Bormann [Page 15]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
NH [Pid] . . . 2*CRC Flag
IH [Pid] . . . 1*CRC NH . . . 2*CRC Flag
H.223 achieves even better numbers by using a per-packet CRC only (2
bytes saved) and, in the best case that the inserted packet is of a
repetitive length that has been defined in the multiplex table, a
common header for both elements of the second frame (1 more byte
saved). The first saving does not seem to be practical with many
current synchronous chips (although it could be made an option, in
particular for asynchronous applications -- some way would have to be
found to protect the compact header then, though); the second saving
is dubious in a more dynamic, multiple-packet-stream environment.
B. Usage Scenarios
Scenario: Two low-bitrate links are in the path between two internet
telephones that use G.723.1 compression for 20 byte audio packets (as
per G.723.1), with C-RTP headers of 2 bytes. These are repeated
every 30 ms.
To simplify the calculations, background traffic consists of a
continuous, infinite length packet. For packet size distributions
found in actual use, the resulting numbers would be more favorable to
compact headers.
For the compact header, the PPP overhead is four bytes; for insertion
headers, it is two bytes; in both cases, any packet that was
interrupted needs to be resumed with an additional overhead of four
bytes. For the 12-bit header without classes, the PPP overhead for
the audio frames also is four bytes; the overhead per fragment of
other data is six bytes.
As an rather lenient performance requirement, we allow a round-trip
delay budget of 300 ms (note that investigations show that this delay
already significantly reduces the mean opinion score). Of the 150 ms
available per path, 70 ms are reserved for delays in the rest of the
path, so 40 ms is the delay budget per link; we neglect transmission
delays. (If better values than 70 ms in the network become
realistic, it is likely that one would want to reduce the overall
delay instead of allocating more of it to the low-speed links).
B.1. GSM Scenario (9600 bit/s)
We assume a transparent, full-duplex 9600 bit/s link as could be
found on a full rate traffic channel in the GSM mobile phone system.
For these considerations, we ignore the additional delays that are
encountered in the air interface and its interleaving mechanisms.
At 1200 bytes per second, a maximum of 36 bytes can be transmitted
per 30 ms; note that for 22 bytes of payload at 1200 byte/s, about 20
Bormann [Page 16]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
ms of the 40 ms delay budget are already taken for the actual sending
of the packet. A regular fragmentation schedule would therefore have
to operate in 20 ms units, at about 24 bytes per fragment (of which
six are taken for fragmentation overhead -- an efficiency of about 75
%). At 1200 bytes per second, the load during a talkspurt is 26/1200
seconds every 30 ms, i.e., 22 ms every 30 ms; the capacity remaining
for data is about 170 byte/s.
It is obvious that an efficient fragmentation mechanism is required
to allow significant data to flow during talkspurts. With insertion
headers, the overhead per packet can be limited to 6 bytes, leaving
room for 8 bytes of actual data per 30 ms, or 270 byte/s.
Note that, as the access delay is very small with a suspend/resume
mode, part of the delay budget could be used by the application for
assembling two G.723.1 frames into one packet (at 40 + 2 C-RTP
bytes); there is then room for 24 bytes of non-audio data per 60 ms,
or 400 byte/s.
B.2. V.34 Modem scenario (24000 to 28800 bit/s)
We assume a link speed of 3000 byte/s as not all V.34 modem
communication reaches the full speed of 3600 byte/s (28800 bit/s).
At this speed, the transmission of 22 bytes of audio payload takes
about 8 ms, so about 32 ms of the 40 ms link delay budget is
available for access delay. With a regular fragmentation schedule
based on 12-bit headers, this allows a fragment size of 90 bytes plus
6 bytes of fragment overhead, i.e. about 7 % loss due to
fragmentation. As 26 out of the 90 bytes that can be sent in 30 ms
are used for the audio packets, an average of 64/96 such 90 byte
fragments can be sent per 30 ms, leading to a remaining data
throughput of about 2000 byte/s.
With compact headers (including the insertion option) and
suspend/resume operation, the audio information can be sent using
only two bytes of overhead per audio packet, leaving 66 of the 90
bytes that can be sent in 30 ms to data packets, of which four bytes
is lost to PPP overhead, resulting in a remaining data throughput of
about 2070 byte/s. If the application makes use of the reduced
jitter of suspend/resume by combining two audio packets into one, 136
of 180 bytes that can be sent in 60 ms are available to data packets,
of which, again, four bytes is lost to PPP overhead, resulting in a
remaining data throughput of about 2200 byte/s.
B.3. ISDN scenario (56000 to 64000 bit/s)
We assume a link speed of 7000 (US) to 8000 (non-US) byte/s. For a
regular fragmentation schedule, similar calculations lead to a
fragment size of 260 to 300 bytes, for about 2 % of fragmentation
overhead. The approximate numbers resulting for remaining data
throughput, based on 64 kbit/s (8000 byte/s) are: 7000 byte/s for a
Bormann [Page 17]
INTERNET-DRAFT The Multi-Class Extension to Multi-Link PPPSeptember 1996
regular schedule of 300 byte fragments, 7070 byte/s for compact
headers, and 7200 byte/s for compact headers making use of double
size packets.
Bormann [Page 18]
