Internet DRAFT - draft-andrades-framing-ext
draft-andrades-framing-ext
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:31:35 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 25 Sep 1996 02:20:08 GMT
ETag: "2e6fcb-b88b-324896d8"
Accept-Ranges: bytes
Content-Length: 47243
Connection: close
Content-Type: text/plain
Network Working Group R. Andrades
INTERNET DRAFT isochrone, Inc.
Document: draft-andrades-framing-ext-00.txt F. Burg
Expires: March 20, 1997 AT&T
September 20, 1996
QOSPPP Framing Extensions to PPP
(draft-andrades-framing-ext-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
The Point-to-Point Protocol (PPP) [2] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
PPP datagrams are often encapsulated in HDLC frames [1] when used
over standard analog modems.
This document describes the extensions to PPP encapsulation and
HDLC framing to support Quality of Service (QoS) over low bandwidth
links.
This document is a submission to the IETF ISSLL working group.
Comments are solicited and should be addressed to the working
group's mailing list at issll@mercury.lcs.mit.edu and/or the author.
Andrades, Burg [Page 1]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
Table of Contents
1. Introduction...............................................3
2. Current Implementation ....................................3
2.1 QOSPPP Extensions to HDLC framing........................3
2.2 QOSPPP Extensions to PPP encapsulation...................7
2.3 QOSPPP Extensions to Link Establishment Protocol.........7
2.4 Planned QOSPPP Features..................................8
3. Comparison with other proposals...........................10
4. Other Possibilities.......................................16
5. Security Considerations...................................18
6. Acknowledgments...........................................19
7. References................................................19
8. Author's Address..........................................20
Andrades, Burg [Page 2]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
1. Introduction
QOSPPP provides an architectural framework for providing multimedia
and other advanced services, requiring QoS over the Internet. Our
current work is aimed at the consumer market which usually uses
comparatively low bandwidth analog modems for Internet access. The
links from the consumer's residences to their Internet Service
Providers usually run the PPP protocol [2] encapsulated in
asynchronous HDLC frames [1], and so our goal was to add QoS to
this framing scheme. The current document describes our attempt to
extend the PPP encapsulation in asynchronous HDLC framing to
support QoS over these links. One goal was to maintain as much
compatibility as possible with current PPP implementations and to
fall back to the standard PPP/HDLC framing scheme if we detect that
the extensions are not available on the peer. The framework also
included a signalling engine which is used to negotiate parameters
for the QoS connections, and a packet scheduler which contains
the actual scheduling algorithms. The signalling protocol could be
Q.2931 or RSVP or a variant of one of these. The term QOSPPP is
used to refer to the entire framework and not just the framing.
The complete QOSPPP architecture will be described in more detail
in a future document.
Several Internet Services Providers still offer SLIP connections;
however, we felt that this would very soon be obsolete and did not
attempt to address it. At this stage we have not attempted to work
out the framing extensions for synchronous HDLC, since it is not
used in the market we are addressing; however, we feel that the
current work can easily be adapted to that area.
Section 2 describes the current implementation and work in progress.
Section 3 compares this framing scheme with those [5,6] proposed by
Carsten Bormann. Section 4 considers merging the features of QOSPPP
with [6].
2. Current Implementation
2.1 QOSPPP Extensions to HDLC framing
The aim of QOSPPP is to allow a customer to run a mix of
applications with varying communications needs. Currently most PPP
implementations offer a single class of service, best-effort, which
is most suited for conventional data applications (e.g. Telnet, ftp,
WWW, email). However, newer Internet applications such as packet
telephony, video conferencing, etc. require a new class of service
with bandwidth guarantees and upper bounds of the delay and jitter
seen by their packets.
Andrades, Burg [Page 3]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
QOSPPP supports four classes of service, ABR, UBR, CBR and VBR. We
use these terms in the same sense as defined by the ATM Forum [7].
However, the basic concepts are the same for any other definition
of class of service.
ABR or Available Bit Rate supports traditional data applications,
which do not need bandwidth guarantees, nor any strict bounds on
their delay and jitter. They typically have variable sized packets.
However, ABR applications ARE QoS aware and will specify their
maximum datagram size, expected bandwidth usage, and maximum
tolerable delays. The class of service is specified in the flowspec
along with other parameters like bandwidth, delay and jitter.
The application programming interface (API) MUST provide an
interface by which the flowspec can be communicated by the
application to the transport stack, but this is out of the scope of
this document. While the network does not guarantee the latter
two, it does use them to estimate buffer sizes and expected load.
UBR or Unspecified Bit Rate is for legacy applications that are not
QoS aware. ABR and UBR are equivalent to the framing layer and so
are both referred to as ABR for the remainder of this document.
CBR or Constant Bit Rate is for applications that transmit data at
regular intervals. The datagrams are usually small and of fixed
length (though the latter is not a requirement). An example is a
packet phone which does not do silence detection. They do have
strict upper bounds on the delay and jitter they can tolerate as
well as strict bandwidth requirements. VBR or Variable Bit Rate is
similar to CBR, except that the rate of packet transmission is not
fixed. The transmission rate may vary upto a maximum rate, and it
also defines a long term average rate. CBR and VBR are equivalent
to the framing layer and so are both referred to as QoS streams
for the remainder of this document.
The framing layer then has to support two classes of datagrams,
normal data applications and QoS. Most of this support is done by a
packet scheduler and signalling engine at a layer higher than the
framing layer, and so will not be discussed in this document.
However, one aspect of QoS that is strongly influenced by the
framing layer is the delay bounds of QoS streams. This is because
the delay allowance of QoS streams tends to be in the range of tens
of milliseconds. However, several popular data applications (e.g.
WWW traffic) tend to use large size packets since they are more
efficient. On a 28,800 link, a 1500 byte packet (which is the MTU
used by most PPP implementations, and many data applications use
the MTU) takes approximately half a second to transmit, making the
link unavailable for that time. (In practice, the bandwidth
available with a 28,800 modem is often less than 28,800, depending
on the line conditions.) This clearly indicates that in order to
support QoS streams on low bandwidth links, some change in the
standard PPP framing is required. One possible way to handle it
would be to use a much smaller MTU. However, in order to support
Andrades, Burg [Page 4]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
delay bounds of around 20 ms for QoS streams, it would be necessary
to restrict the MTU of ABR traffic to around 36 bytes, which is
clearly unacceptable.
Another approach (which is what QOSPPP does) is to allow an ABR
datagram that is currently being transmitted to be preempted by a
QoS stream with stricter delay bounds. When the QoS packet is
complete, the preempted ABR datagram will resume transmission. The
difference between preemption and conventional fragmentation is
that each resuming segment of the ABR datagram does NOT carry a
header telling the receiving end how to put the pieces back
together again. The preemption is indicated by stuffing a
preemption flag byte which is defined as 0x7c. The end of
preemption is indicated by transmitting a standard HDLC Flag byte.
When preemption ends, the interrupted frame is automatically
resumed at the point where it was suspended, with no extra header
bytes. The current implementation supports a single level of
preemption, however we are planning a new version with support for
multiple levels of preemption, see section 2.4.
In this document we use the terms priority and preemption class
interchangeably although that may not be the common usage.
The preemption is explained by the following diagram. Assume that
there are two active streams, a TCP stream (maybe a Web browser)
which is ABR, and a voice stream (the latter for a packet phone
application) which is CBR (or VBR if silence detection is
implemented). Initially, in the absence of any voice data, the
framer begins transmission of a packet of the TCP stream. After
some time, a voice packet is queued for transmission and the
framer suspends transmission of the TCP stream to begin sending
the voice packet. When transmission of the voice packet is
complete, the framer resumes transmission of the suspended TCP
packet. Note that one voice packet can not interrupt another
voice packet. The payload size of the voice packet (16 bytes in
the example), depend on the encoding algorithm used. Also note
that each FCS in the following diagram protects only the frame
it is a part of, (the one that is terminated by the HDLC Flag byte
immediately after the FCS), and not any intermediate (preempting)
frames, Each stream can negotiate the use of an FCS of a different
strength (size). The new Suspend Flag byte needs to be added to the
ACCM for transparency. Note that in the diagram, and elsewhere in
this document, the term PID always refers to the PPP protocol ID.
Andrades, Burg [Page 5]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
Preempted packet - (starts earlier in time)
--------------------------- - - - -----------------------------
|HDLC |IP PID | TCP data \ \ TCP data |FCS |HDLC |
|Flag |0x21 | \ \ (contd.)|(2 bytes) |Flag |
|0x7e | | \ \ | |0x7e |
------------------------------ - - - --------------------------
Suspend Resume
/ \
/ \
/ \
/ \
/ \
/ Preempting packet \
/ (Starts later in time - \
/ completes earlier) \
----------------------------------------
|Suspend |CBR |Voice data|FCS |HDLC |
|Flag |PID | 16 bytes |(0 or 2|Flag |
|0x7c | | | bytes)|0x7e |
----------------------------------------
As can be seen from the preceding diagram, the preempting packet's
frame format is the same as the standard PPP frame except for the
use of a new Suspend Flag (0x7c) instead of the HDLC Flag (0x7e).
One other difference is that the length of the FCS field can be
different for different PIDs. PPP currently defines three different
FCS', 16-bit, 32-bit and NULL FCS. We use the 16-bit FCS for all
data streams (it is the default anyway). The NULL FCS can be
negotiated for CBR streams that have a small MTU by the signalling
engine. However, this choice, if desired, must be made by the
application. The interface by which the application may negotiate
the choice of an FCS is out of the scope of this document. In
any examples in this document, the length of the FCS shown is just
for illustration.
In the special case, when we have only a single active QoS stream,
we omit sending the CBR PID in preempting frames, since it is
implicit from the Suspend Flag, and reduces the Framing overhead
by a byte.
Andrades, Burg [Page 6]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
2.2 QOSPPP Extensions to PPP encapsulation
All CBR and VBR streams are each assigned a unique PPP protocol ID
(PID) by the signalling engine. These PID values are taken from
the unused values as specified in [8]. We plan to get a range of
these unused PIDs allocated for this purpose. Unlike the PIDs
currently assigned to protocols by the IETF, the PIDs used by
QOSPPP are not necessarily the same in both directions, because
of the way the signalling engine works. We try to pick the PIDs
from the 1-byte PID space (and since we do not expect too many
streams to be simultaneously active over these low bandwidth
links, it isn't difficult to find enough 1-byte PIDs).
2.3 QOSPPP Extensions to Link Establishment Protocol
PPP uses the Link Control Protocol (LCP) [2] to establish
parameters for the link. Up-to-date values of the LCP Code field
are specified in the most recent "Assigned Numbers" RFC [8].
QOSPPP adds the following configuration option:
--------------------------------------------------------
|Option | Length | version | Preemptive | Link Speed |
|0x55 | = 8 | (4 bytes) | scheduling | Monitoring |
| | | | (1 byte) | (1 byte) |
--------------------------------------------------------
Option: This is a new LCP configuration option code value.
Version: This field is currently set to 1. Future versions
may set this field to other values to indicate other
preemption schemes.
Preemptive scheduling: This is set to 0 to indicate that QoS
streams are not currently supported (even though the peer
apparently is QOSPPP-enabled). The current QOSPPP framing uses a
value of 1 in this field. In the future, we plan to use this field
to indicate the number of levels of preemption supported
(Currently it is one level).
Link Speed Monitoring: This is currently set to 0 to indicate
that Link Speed Monitoring is not required. The purpose of
Link Speed Monitoring is to enable an implementation to track
changes in the link bandwidth and adjust it's packet scheduling
accordingly. No protocol has yet been defined for Link Speed
Monitoring.
Andrades, Burg [Page 7]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
The node at one end sends a configuration message indicating that
it supports preemption, and the maximum number of preemption levels
it supports. If the other node responds with a reject (i.e. it is
a non QoS-aware implementation and does not recognize the new LCP
option code), then the sender will disable the preemption
capability and send a new configuration message without the
preemption option (and disable the preemption feature locally for
the current session). If the other side responds with a NAK
requesting a smaller number of levels of preemption, we will
adjust our behavior accordingly and resend the configuration
message reflecting the requested changes.
2.4 Planned QOSPPP Features
We will try to choose the PID values so that their Hamming distance
is at least two, allowing single bit errors in the PID field to be
detected.
In the QOSPPP Framing engine the FCS field can be turned off for
individual CBR and VBR streams. We could also adopt Carsten's idea
[6] of using an 8-bit CRC for CBR and VBR streams. Thus the
effective Framing overhead can be reduced by a byte for CBR and
VBR streams. We propose to use the 8-bit FCS described in the V.76
specification [9], unless the IETF already has a standard for
an 8-bit FCS.
Another planned extension to QOSPPP is multiple levels of
preemption. In this we will put different streams into
different preemption classes and allow a packet of a stream of a
higher preemption class to preempt a currently transmitting packet
of a stream of a lower preemption class. Currently, we do not
plan to support dynamic priorities (where two streams' relative
priorities can change dynamically). The QOSPPP frame format can
support multiple preemption levels without any change.
Multiple preemption levels are explained by the following diagram
that shows two levels of preemption. Assume that there are three
active streams, a TCP stream (maybe a Web browser), a video
stream and a voice stream (the latter two for video conferencing).
Assume that the video stream belongs to a higher preemption level
than the TCP stream and the voice stream belongs to a higher
Andrades, Burg [Page 8]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
preemption level than the video stream. Initially, in the absence
of any voice or video data, the framer begins transmission of a
packet of the TCP stream. After some time, a video packet is queued
for transmission and the framer suspends transmission of the TCP
stream to begin sending the video packet. Before transmission of
the video packet is complete, a voice packet is queued for
transmission. The framer suspends transmission of the video stream
to begin sending the voice packet. When transmission of the voice
packet is complete, the framer resumes transmission of the
suspended video packet. When transmission of the video packet is
complete, the framer resumes transmission of the suspended TCP
packet. Note that a video packet can not interrupt a voice packet
or another video packet, and one voice packet can not interrupt
another voice packet.
Preempted packet - (starts earlier in time)
--------------------------- - - - -----------------------------
|HDLC |IP PID | TCP data \ \ TCP data |FCS |HDLC |
|Flag |0x21 | \ \ (contd.)|(2 bytes) |Flag |
|0x7e | | \ \ | |0x7e |
------------------------------ - - - --------------------------
Suspend Resume
/ \
/ \
/ \
/ \
/ \
/ First level of Preemption \
/ (Starts later in time - \
/ completes earlier) \
--------------- - - - - ----------------
|Suspend |CBR |Video data|FCS |HDLC |
|Flag |PID |'n' bytes |(1 or 2|Flag |
|0x7c | | | bytes)|0x7e |
--------------- - - - - ----------------
Suspend Resume
/ \
/ \
/ \
/ \
/ \
/ Second level of Preemption \
/ (Starts still later in time - \
/ completes first) \
----------------------------------------
|Suspend |CBR |Voice data|FCS |HDLC |
|Flag |PID |'m' bytes |(1 or 2|Flag |
|0x7c | | | bytes)|0x7e |
----------------------------------------
Andrades, Burg [Page 9]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
Note that the suspended packets have to be resumed in the reverse
(stack-like or LIFO) order; i.e. if streamA preempts streamB
preempts streamC, then when streamC completes, streamB must
resume (and complete) before streamA is resumed. Currently we do
not expect to support resumption of suspended packets in a
different order (which, by the way, would necessarily imply
implementing dynamic priorities).
3. Comparison with other proposals
In all the descriptions below we are assuming that the
address-control field compression and protocol field compression
options have been negotiated by the link control protocol, and that
all PIDs used for the real-time streams are 1 byte.
Case 0. The QOSPPP fragmentation format
|--------------------------------------|
|Preemption FLAG |
|--------------------------------------|
|PID (1 byte - opt) |
|--------------------------------------|
|Fragment Data |
|--------------------------------------|
|FCS (2 bytes or 0 bytes - negotiable) |
|--------------------------------------|
|HDLC Flag |
|--------------------------------------|
This frame has between 5 and 2 bytes of overhead per preemption;
the minimum of two bytes is in the case when there is only a single
active stream of a high preemption class, and it has been
negotiated not to require the use of a CRC; the maximum of five
bytes is when there are multiple active streams of high preemption
classes (either in the same class, or in preemption classes), and
they require the use of a 2 byte CRC. We could also consider using
a 1 byte CRC (as suggested by Carsten Bormann), for streams whose
packets are rather short. Note that there is no overhead on the
interrupted packet. Therefore every low priority packet carries 5
bytes of framing overhead (regardless of whether it is preempted
or not), and every higher priority packet carries 2 to 5 bytes of
overhead.
There is no limit on the number of preemption levels, except the
number of bits in a PID (though not all combinations are valid).
In the case of multiple levels of preemption, it assumes that
suspended frames will be resumed in the reverse order, from that
in which they were suspended.
Andrades, Burg [Page 10]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
In the absence of preemption, the frame format is exactly the same
as regular PPP.
We will consider the following proposals from Carsten Bormann and
try to consider all the optimizations too.
Case 1. Using PPP Multi-Link as-is (short sequence number fragment
format)
|--------------------------------------|
|HDLC Flag |
|--------------------------------------|
|PID (1 byte) |
|--------------------------------------|
| B | E | 0 | 0 | sequence number |
|--------------------------------------|
|sequence number |
|--------------------------------------|
|Fragment Data |
|--------------------------------------|
|FCS (2 bytes) |
|--------------------------------------|
|HDLC Flag |
|--------------------------------------|
In this scheme, every lower priority packet needs to be sent in at
least two MLPPP frames. (Since we do not know whether it is going
to be interrupted or not, we must begin transmitting with the "E"
bit set to "0". Therefore, even if it is not interrupted, we need
to send a final (empty) fragment with the "E" bit set to "1" to
terminate the packet). Now, the MLPPP frame has 7 bytes of framing
overhead, therefore every lower priority packet has 7*2= 14 bytes
of framing overhead. However, the MLPPP packet actually carries a
PPP packet within it adding an additional 1 byte overhead (for the
PPP PID) making the total framing overhead 15 bytes. We can save
one byte by not transmitting two consecutive Flag bytes making the
total framing overhead 14 bytes as opposed to 5 bytes for a normal
PPP frame. For every preemption, the lower priority packet needs to
be terminated with an MLPPP trailer (3 bytes) and restarted with an
MLPPP header (4 bytes) adding an additional 7 bytes overhead.
Additionally, the preempting packet needs it's PPP header of 5
bytes, giving a total framing overhead of 12 bytes per preemption.
Dropping consecutive Flag bytes will save two bytes giving a total
framing overhead of 10 bytes per preemption as opposed to 5 bytes
for a normal PPP frame. In case the interrupted packet is resumed
near it's end (e.g. it has fewer than say 8 bytes left to
transmit), we can assume that it will not be interrupted again and
can send the last fragment with the "E" bit set to "1", thus
eliminating the 6 bytes of the empty MLPPP header at the end.
Andrades, Burg [Page 11]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
It supports a single level of preemption.
It can be used even if the other end does not support QoS. This
however, assumes that the other end supports MLPPP; We are not sure
how many implementations, (aside from Windows NT 4.0), and how
many service providers support MLPPP for analog lines.
Case 2. Extending PPP Multi-Link to multiple class (short sequence
number fragment format)
|--------------------------------------|
|HDLC Flag |
|--------------------------------------|
|PID (1 byte) |
|--------------------------------------|
| B | E | class | sequence number |
|--------------------------------------|
|sequence number |
|--------------------------------------|
|Fragment Data |
|--------------------------------------|
|FCS (2 bytes) |
|--------------------------------------|
|HDLC Flag |
|--------------------------------------|
The difference between this scheme and case 1 is that it supports
4 levels of preemption. However, now preempted packets carry an
MLPPP header (plus a PPP PID), instead of a normal PPP header
(except for one of the preemption levels which uses normal PPP
frames). Thus the preempted packets carry (7(MLPPP header) +
1(PPP PID) = ) 8 bytes of framing overhead per packet. So the total
framing overhead per preemption is (7 (preempted) + 8 (preempting)
= ) 15 bytes. Again, dropping consecutive Flag bytes will save two
bytes giving a total framing overhead of 13 bytes per preemption
as opposed to 5 bytes for a normal PPP frame.
It is backward compatible to case 1; i.e. if the remote end does
not support QoS, we can fall back to case 1, restricting ourselves
to a single level of preemption.
In the case of multiple levels of preemption, suspended frames can
be resumed in any order, not necessarily the reverse order from
that in which they were suspended.
Andrades, Burg [Page 12]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
Case 3. The Compact Fragment Format (Normal header)
|--------------------------------------|
|HDLC Flag |
|--------------------------------------|
|R | Sequence | Class | 1 |
|--------------------------------------|
|Fragment Data |
|--------------------------------------|
|FCS (2 bytes) |
|--------------------------------------|
|HDLC Flag |
|--------------------------------------|
It supports 7 levels of preemption.
In the case of multiple levels of preemption, suspended frames can
be resumed in any order, not necessarily the reverse order from
that in which they were suspended.
The header above has 5 bytes of overhead per frame which is the
same as the normal PPP header. However [6] seems to imply that all
fragments will be sent using the header described above, not just
the interrupting packet. (This needs to be clarified with Carsten
Bormann.) This means that every time a lower priority packet is
preempted by a higher priority packet, the lower priority packet
is terminated by an FCS and Flag byte (3 bytes), and when it
resumes, it will carry a 2 byte header, adding 5 bytes of overhead
per preemption. Also the Higher priority packet will need 5 bytes
of framing overhead, making the total framing overhead (5+5=) 10
bytes per preemption. Again, dropping consecutive Flag bytes will
save two bytes giving a total framing overhead of 8 bytes per
preemption as opposed to 5 bytes for a normal PPP frame.
Case 4. The Compact Fragment Format (Insertion Header)
|--------------------------------------|
|HDLC Flag |
|--------------------------------------|
|Length L | C | 0 |
|--------------------------------------|
|Inserted Packet (Length L) |
|--------------------------------------|
|FCS (1 byte) |
|--------------------------------------|
It supports 2 levels of preemption.
Andrades, Burg [Page 13]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
This frame format carries 3 bytes of overhead for the preempting
packet. Also, it does not impose any additional overhead on the
packet being interrupted.
It does have the restriction that the higher priority packet be
not more than 64 bytes in length.
Comparison of Overhead
Cases 1 & 2 have more overhead than the rest. Case 1 is useful
only if it is necessary to support (a single level of) preemption
even for links where the peer does not support QoS. Even this is
debatable for two reasons:
(1) How many implementations actually support MLPPP for analog
lines, and,
(2) Preemption by itself is generally not sufficient to support
QoS for analog lines, one also needs to do some form of header
compression, especially considering the increased size of the
MLPPP headers. Would the remote end which does not have support
for QoS support the header compression scheme?
Case 2 does not seem useful considering that it requires the remote
end to support a non-standard extension to MLPPP. If the remote end
has to be modified to support this extension, one should question
why it can not be modified to support some other, more efficient,
extension. It does have the advantage of being able to gracefully
fallback to case 1, but as mentioned above, the value of this
advantage seems to be rather dubious. We shall not consider cases
1 & 2 any longer.
Case 4 appears to have less overhead (3 bytes as opposed to 5
bytes for case 0 & 8 bytes for case 3), than any other. However,
one of the optimizations that caused a 1 byte reduction in
overhead (the smaller FCS) can also be applied to cases 0 and 3.
The second optimization (dropping the intermediate Flag byte) is
achieved mainly by putting a length field in the header and
shrinking the class number to 1 bit. The former restricts the
length of high priority packets to 64 bytes which may be O.K., the
latter restricts the number of high priority streams to 2, which
makes it O.K. as an optimization of case 3 rather than as a
separate case (which anyway, is what Carsten presents it as).
Let us examine cases 0 & 3. Consider the following scenarios for
cases 0 & 3 (with case 4 as an optimization of case 3).
1. normal case, case 0 has 5 bytes overhead, case 3 has 8 bytes
2. 8-bit FCS, overhead reduces by 1 byte for both cases.
3. No FCS, overhead reduces by 2 bytes for both cases.
Andrades, Burg [Page 14]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
4. A single high priority stream, reduces case 0 overhead by 1
byte by dropping the PID. If the length of the packet is less than
64 bytes, case 3 reduces to case 4. This means that cases 0 & 3 are
identical, assuming the FCS is the same size in both.
5. Upto 2 high priority streams whose packet lengths are less than
64 bytes, and which use an 8-bit FCS can have their overhead reduced
to 3 bytes for case 3 by using the case 4 optimizations. This
compares with 4 bytes for case 0 under the same conditions, except
that you can do it for a greater number of streams.
6. Case 0 overhead can be reduced by 1 byte by dropping the
intermediate Flag byte, however this can be done only for streams
that have fixed size packets, and it carries the danger of two
packets (the preempted and the preempting,) being corrupted if
any byte of the preempting packet is dropped.
As can be seen, there does not appear to be a clear advantage
of one scheme over the other.
Note that the frame formats of cases 1 & 2 actually indicate
fragmentation rather than preemption, since each frame carries
a header telling the receiver how to put it back together. The
idea behind preemption is precisely to avoid the overhead of this
kind of header. However, although the frame format makes it look
like fragmentation, calling it preemption is justifiable
from the point of view of the actual operation of the protocol;
i.e., with conventional fragmentation, the stack will decide
on how to fragment a packet either when it is given a packet from
the higher layer, or, when it decides to begin transmission. In
preemption, the decision of how, when, etc. to "fragment" is made
at the time a higher priority "preempting" packet becomes eligible
for transmission. This distinction can only be made at the sending
side, for the receiver it does look like fragmentation.
Comparison of error detection capability
Case 3 packets have a sequence number which will allow it to detect
a lost fragment. Of course, even in case 0, lost fragments can be
caught by the FCS, but the sequence number provides an additional
check.
Comparison of number of levels of preemption
Consider cases 0 and 3 alone as case 4 is an optimization of case 3.
Case 0 supports an arbitrary number of levels of preemption,
limited only by the PID space. Case 3 supports 7 levels of
preemption. There does not seem to be much to choose between them
here as 7 levels of preemption are probably enough.
Andrades, Burg [Page 15]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
Comparison of support for dynamic priorities
Case 3 appears to have slightly better support for dynamic
priorities. However, let us see if this advantage is meaningful.
There is one way in which the use of dynamic priorities can affect
the framing format. Consider the case where there are three stream
A, B and C, in the increasing order of priorities. Assume that the
priorities are dynamic so the priority ordering may change over
time. Now consider a scenario where stream B has preempted stream
A and stream C has preempted stream B. Suppose stream A gets a
priority boost making it temporarily of higher priority that stream
B (but lower than stream C). Therefore when stream C completes
transmission of it's packet, there is an issue of whether we should
resume transmission of stream A or stream B. Carsten's proposals
(cases 2 & 3) give the implementation the choice in this matter,
QOSPPP does not.
This does not mean that dynamic priorities are impossible with
QOSPPP. Dynamic priorities can still be used in controlling the
decision of preemption of one stream by another, they simply can
not be used for making the resumption decision. Also, the scenario
above could be considered farfetched by some. For that matter, the
whole idea of dynamic priorities might be considered irrelevant
for the applications we are considering; the alternative is to
allow a slightly larger jitter, which might be perfectly
acceptable.
Case 0, being limited to a strict stack-like sequence of
suspends-resumes might be slightly simpler to implement.
4. Other Possibilities
Based on the discussion above, we propose a new framing format
which attempts to borrow the best features of both the QOSPPP
framing and Carsten's proposals.
Use a preemption flag and the requirement that packets be resumed
in the reverse order from that in which they were suspended.
In the case of a single higher priority stream, keep the option of
dropping the PID byte. This however, has to be negotiated by LCP.
Andrades, Burg [Page 16]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
QOSPPP uses UDP header compression. This consists of not
transmitting the UDP and IP headers of any packet that is
associated with a specific PID. The receiver automatically prepends
the UDP & IP headers to every incoming packet.The information needed
for the headers is transmitted when the PID is negotiated by the
signalling engine (the checksum can be generated by the receiver
on the reconstructed received packet - or we can use the
optimization of setting the checksum to 0). Carsten proposes prefix
elision [6] which is basically associating each class or PID with a
prefix of bytes that begin every packet belong to that class or PID
and then not transmitting those bytes. The receiver automatically
prepends the prefix to every packet it receives. UDP header
compression gives better reduction in overhead than prefix elision
for UDP streams. It does not handle non-UDP streams, but we assume
Van Jacobson does a fairly good job at that. Are there other
non-UDP, non-TCP streams that we have to consider? If so, we can do
prefix elision for these streams. (This will have to be negotiated
by the signalling protocol on a per-stream basis).
The sequence number gives us some additional error detection
capability. However, it is more useful for the packet being
interrupted than the interrupting packet, as the former is spread
out over a longer time and has a higher probability of being
corrupted. Therefore we will put it only in the packet being
resumed. This also has the advantage that in case a packet is not
interrupted, it will have exactly the same format as a regular PPP
frame. We shall therefore call it a fragment number and every
fragment being resumed will have this as the first byte. The first
fragment has an implicit fragment number of 0.
The signalling protocol will negotiate the size of the FCS for each
stream.
We can use one of Carsten's values of 0xDE or 0xC3 for the
Preemption flag. Maybe we should run tests over a PPP link (before
the byte stuffing stage) rather than over an Ethernet as he did.
The use or non-use of dynamic priorities is an independent decision
which will not affect the frame format. Also, it needs to be
implemented on the sending side alone (for the framing scheme we
are considering), so both sides need not have it.
The frame format is shown below.
Andrades, Burg [Page 17]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
|--------------------------------------|
|Preemption Flag |
|--------------------------------------|
|PID (opt) |
|--------------------------------------|
|Fragment Data |
|--------------------------------------|
|FCS (1, or 2 bytes) |
|--------------------------------------|
|HDLC Flag |
|--------------------------------------|
|Fragment # for resuming packet |
|--------------------------------------|
We can also continue to use the optimizations of case 4 (Insertion
headers) as follows.
|--------------------------------------|
|Preemption Flag |
|--------------------------------------|
|Length L | S | 0 |
|--------------------------------------|
|Inserted Packet (Length L) |
|--------------------------------------|
|FCS (1, or 2 bytes) |
|--------------------------------------|
This is similar to that described by Carsten. The difference is
that now we are not using the concept of Class any more, so the
"C" bit becomes a stream identifier and is renamed to be an "S"
bit (a purely cosmetic change). There can be only two such streams,
and they must be negotiated by a signalling protocol. A stream using
insertion headers can continue to use the normal preemption frame
format interchangeably.
This scheme has the standard 5 bytes of PPP framing overhead for
lower priority packets that are not interrupted, and 6 to 3 bytes
of framing overhead per preemption. In the "normal" case when we
have multiple high priority streams and they all use a 1 byte FCS,
there will be 5 bytes of framing overhead per preemption, which is
the same as regular PPP. Upto two of these streams can take
advantage of the insertion header format to reduce the overhead to
3 bytes.
5. Security Considerations
This document does not raise any new security issues.
Andrades, Burg [Page 18]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
6. Acknowledgments
Much of the work in implementing the QOSPPP architecture and
testing the concepts presented in this document was done by
Murali Aravamudan and Kumar Vishwanathan of isochrone, Inc.
Andreas Papanicolau and Khasha Mohammadi of AT&T also provided
many helpful insights in the design of the architecture.
7. References
[1] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1662,
STD 51, Daydreamer, July 1994.
[2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
RFC 1661, STD 51, Daydreamer, July 1994.
[3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
Daydreamer, January 1994.
[4] McGregor, G., "The PPP Internet Control Protocol", RFC 1332,
Merit, May 1992.
[5] Bormann, Carsten, "Providing integrated services over
low-bitrate links", work in progress, Internet Draft
(draft-ietf-issll-isslow-00.txt), Universitaet Bremen,
June 1996.
[6] Bormann, Carsten, "The Multi-Class Extensions to Multi-Link
PPP", work in progress, Internet Draft,
(draft-ietf-issll-isslow-mcml-00.txt), Universitaet Bremen,
September 1996.
http://www-rn.informatik.uni-bremen.de/research/mcml.html,
Universitaet Bremen, July 1996.
[7] "ATM User-Network Interface (UNI) Specification Version 3.1",
The ATM Forum, 1995.
[8] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, USC/Information Sciences Institute, October 1994.
[9] Burg, F., editor, "Recommendation V.76 - Generic Multiplexer
using V.42 LAPM-based procedures", International
Telecommunication Union, April 1996.
Andrades, Burg [Page 19]
INTERNET DRAFT QOSPPP Framing Extensions to PPP September 20, 1996
8. Author's Address
Questions about this memo can be directed to:
Richard Andrades
isochrone, Inc. Phone: (908) 544 5508
One Main Street Fax: (908) 544 2059
Suite 511 Email: richard@isochrone.com
Eatontown, NJ 07724
Fred M. Burg
AT&T
307 Middletown-Lincroft Road Phone: (908) 576 4322
Room 3L209 Fax: (908) 576 4689
Lincroft, NJ 07738 Email: fred.burg@att.com
Andrades, Burg [Page 20]
