RFC 2686 (rfc2686) - Page 2 of 11

The Multi-Class Extension to Multi-Link PPP

RFC 2686      The Multi-Class Extension to Multi-Link PPP September 1999


   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.  The PPP extensions defined in this document allow a
   sender to fragment the packets of various priorities into multiple
   classes of fragments, allowing high-priority packets to be sent
   between fragments of lower priorities.

   A companion document based on these extensions [5] defines a
   suspend/resume-oriented solution for those cases where the best
   possible delay is required and the senders are of type 1 [1].

1.1.  Specification Language

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

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-
   priority packets are likely to have on the order of 22 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



Bormann                     Standards Track