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 and John Wroclawski , or via its WG mailing list . 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]