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