PPP Working Group Richard Shea
INTERNET DRAFT Bay Networks
Category: Internet Draft
Title: draft-ietf-pppext-l2tpdwin-00.txt
Date: June 1998
L2TP Dynamic Data Window Adjustment
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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``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 ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
Abstract
The Layer Two Tunneling Protocol (L2TP) defines the specification
of congestion window sizes for data sessions. In addition, an LNS
is given the capability to turn off sequence number processing for
a data session, provided the LAC did not include the Sequencing
Required AVP during session setup. This document specifies a
mechanism whereby an L2TP peer can dynamically change the window
size values being used for a data session, in order to provide the
flexibility to operate with smaller window sizes when history-bound
protocols are operating over a session, and larger window sizes
when no history-bound protocols are operating over a session.
1. Introduction
In the L2TP protocol sequence numbers are used for preserving
packet order, detecting packet loss, and congestion control. An
affective window size value for congestion control is influenced in
Shea expires December 1998 [Page 1]
INTERNET DRAFT June 1998
opposite directions by two things. First, in the case where
protocols with history are being carried, the window size must be
small enough so that forced packet loss is not excessive in the
case of a real packet drop where resynchronization is necessary.
At the same time, the larger the delay between the LAC and LNS, the
larger the window size should be so that the available bandwidth
between the LAC and LNS is not underutilized.
Unfortunately, the L2TP protocol specifies that the window sizes
for a session are determined when the session is established, at a
time before it is known whether or not protocol with history will
be operating over the session.
It is important for L2TP to provide the flexibility to maximize
performance for the cases where history-bound protocols are
operating over a data session for a tunnel which is operating over
a lossy network or where no history-bound protocols are operating
over a data session being tunneled over a high-delay path. Because
the knowledge of whether history-bound protocols will be operating
over a data session is not known at the time of session setup, a
mechanism for dynamically updating the data session window sizes is
needed.
1.1 Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL, or MANDATORY -- This item is an absolute
requirement of the specification.
o SHOULD or RECOMMEND -- This item should generally be followed
for all but exceptional circumstances.
o MAY or OPTIONAL -- This item is truly optional and may be
followed or ignored according to the needs of the implementor.
1.2 Terminology
This draft assumes the reader is knowledgable about terms found in
[1]. In addition, the following terms are used in this document:
History-Bound Protocol
Any protocol where secondary information is passed along with
data in the protocol packets where synchronization of such
secondary information between the two peers is necessary, and
where this synchronization takes place across packet
Shea expires December 1998 [Page 2]
INTERNET DRAFT June 1998
boundaries. This is a typical property of compression and
sometimes encryption protocols, although most protocols also
have an operational mode where synchronization across packet
boundaries is not necessary.
2. Protocol overview
The current practice for L2TP is for window sizes to be indicated
at the time of session setup, and for these window sizes to remain
the same for the life of the session.
This document describes an operational addition to L2TP to allow
data session window sizes to change during the life of a data
session.
An L2TP implementation SHOULD start the session with a window size
which is appropriate for maximizing performance assuming that a
history-bound protocol will not be used during the life of the
session (this includes the option of no flow control). Ideally
this is done with knowledge of the bandwidth and delay
characteristics of the path between the LAC and LNS. It is
RECOMMENDED that the bandwidth and delay for the path between an
LNS and LAC be configurable.
When a history-bound protocol is negotiated within the data
session, the window size MUST be changed to a value which is
appropriate for maximizing performance for history-bound
protocols. If the data session is tunneled over a path which is
known to be reliable, or PPP reliable mode ([2]) has been
negotiated for the data session the window size MUST NOT be changed
due to detected negotiation of a history-bound protocol. This
document recommends a window size between 2 and 4 for data sessions
where a history-bound protocol is operating and reliability is not
provided by PPP or for the path between the LAC and LNS.
An implementation MAY start with a window size appropriate for a
data session where a history-bound protocol is operating, and later
increase the window size based on history-bound protocols not being
in operation over the data session.
An implementation MAY also change the window size to provide larger
window sizes for some data session and smaller window sizes for
other data sessions, based on other criteria. This may be decided,
for example, based on the authentication credentials for each
session.
3. Protocol additions
This document specifies no new AVPs or message types, but does
Shea expires December 1998 [Page 3]
INTERNET DRAFT June 1998
specify the use of an existing AVP in a message that it currently
is not found in.
The Receive Window Size AVP is used to communicate the changing of
window size after a session has been established. This is done by
including the Receive Window Size AVP in the Set-Link-Info (SLI)
message.
The format for this is given below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set-Link-Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the L2TP control message header, message type AVP,
and ACCM AVP in the Set-Link-Info message are given in [1].
Receive Window Size
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0|0|0| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Receive Window Size AVP encodes the window size being advertised
for this call. Attribute is 10, indicating Receive Window Size,
and is marked optional for purposes of compatibility with peers who
do not support this document. This AVP is optional. The Size
value indicates the number of received data packets the sender of
the SLI will buffer for this call, which is also the maximum number
of data packets the receiver of the SLI should send before waiting
for an acknowledgment.
Upon reception of the SLI with Receive Window Size AVP, the
receiver of the SLI MUST begin operating under the rules for
Receive Window Size AVP values received during data session setup.
The receiver of the Receive Window Size AVP in the SLI SHOULD also
send their own SLI with Receive Window Size AVP present based on
Shea expires December 1998 [Page 4]
INTERNET DRAFT June 1998
the value that was received. A Receive Window Size AVP value sent
in an SLI message prompted by the reception of Receive Window Size
AVP in an SLI should reflect the same nature of change for the
local receive window size change as was caused by the change in the
peer's receive window size.
4. Security Considerations
Security is not addressed in this document.
References
[1] A. Valencia, et al, "Layer Two Tunneling Protocol", Work In
Progress: draft-ietf-pppext-l2tp-11.txt, May 1998
[2] D. Rand, "PPP Reliable Transmission". RFC 1663
Author's Address
Richard Shea
Bay Networks
125 Nagog Park
Acton, Massachusetts 01720
rshea@BayNetworks.com
Shea expires December 1998 [Page 5]
INTERNET DRAFT June 1998
