PPP Working Group Richard Shea INTERNET DRAFT Nortel Networks Category: Internet Draft Title: draft-ietf-pppext-l2tpdwin-01.txt Date: November 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 ftp.ietf.org, 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 maximum 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, rate pacing, and congestion Shea expires May 1999 [Page 1] INTERNET DRAFT November 1998 control. An effective window size value for congestion control is influenced in 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 due to rate pacing and congestion control. 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 and 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. It is also not possible in all cases for the LAC to detect when a history-bound protocol is being used or not. A mechanism is also included so the LNS can inform the LAC as to whether or not history-bound protocols are being run over the link. 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: Shea expires May 1999 [Page 2] INTERNET DRAFT November 1998 History Application information that is transferred between peers that spans the information conveyed in more than one datagram. History-Bound Protocol A protocol that uses a history during its operation. The canonical example of such protocols in the context of PPP is compression protocols. While compression protocols can be run in a mode where history is not kept between packets, there are some implementations that do not support such a mode; nor is such a mode always the most desirable mode of operation. 2. Protocol overview The current practice for L2TP is for data session maximum window sizes to be indicated at the time of session setup, and for these maximum window sizes to remain the same for the life of the session. This document describes an operational addition to L2TP to allow data session maximum window sizes to change during the life of a data session. There are several factors that an implementation can use when deciding on a value for its maximum receive window size: o Rate Pacing - Based on the access speed of the physical connection of the client to the LAC, the LAC may desire to rate pace the data to stay at the rate that the physical connection can handle. o Congestion Control - Based on the load on the box or relative priority of the tunneled user identity. o Operation of history-bound protocols on the link - In order to get reasonable performance on a link using history-bound protocols in the face of packet loss, the maximum window size should be kept small (4 packets or so). Furthermore, the detection of whether or not a history-bound protocol is running over the link is not always possible for an L2TP endpoint. Specifically, a LAC implementation generally does not (and perhaps for performance reasons should not) inspect PPP traffic being forwarded between the LNS and the client being Shea expires May 1999 [Page 3] INTERNET DRAFT November 1998 tunneled. The additions to the protocol suggested here are therefore to: 1. Provide a method for the LNS to indicate to the LAC whether or not any history-bound protocols are operating over the link. 2. Provide a method for the LNS and LAC to communicate changes in their maximum receive window sizes to each other. To provide both of these mechanisms a new message is specified. When this message is sent from the LNS to the LAC it includes the current state of history-bound protocol operation and a new maximum receive window size. When this new message is sent from the LAC to the LNS it includes a new maximum receive window size. 3. Protocol additions This document specifies that the protocol be extended with a new message type: Session-Update (SU). This new message is used during the life of a session to communicate session update information for a data session. This document further specifies two AVPs that can optionally be included in the SU message. For SU messages sent from the LNS to the LAC a new AVP indicating the current state of history protocol operation over the tunneled session can be included. Both the LNS and the LAC can send the SU with the Receive Window Size AVP included to change the maximum receive window size for the data session. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Update | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | History Operation State | | (LNS->LAC only) | +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Window Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the L2TP control message header is given in [1]. The Message Type AVP for this message contains the value [TBD] indicating that this message is a Session-Update message. Shea expires May 1999 [Page 4] INTERNET DRAFT November 1998 History Operation State 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [TBD] | 0 |V|H| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ History Operation State encodes the state of history-bound protocol operation using two bits. The V (VJ) bit indicates whether or not VJ TCP/IP header compression [3] is operating over the link. If the V bit is one (1) this indicates that VJ packets are being sent over the tunneled data session be the LNS. This informs the LAC that upon detection of lost data packets, an indication should be sent over the physical connection to the client that a packet was lost (e.g. the LAC can force a CRC error on the physical connection to the client). If the V bit is zero (0) this indicates that VJ packets are not being sent over the tunneled data session by the LNS. The H (History) bit is set if any other history-bound protocol (other than VJ compression) is being run over the tunneled session. Attribute is [TBD], indicating History Operation Status, and is marked mandatory. This AVP MUST be present in an SU sent by the LNS. This AVP MUST NOT be present in an SU sent by the LAC. 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 mandatory. This AVP itself is optional. The Size value indicates the number of received data packets the sender of the SU will buffer for this call, which is also the maximum number of data packets the receiver of the SU should send before waiting for an acknowledgment. 4. Protocol Operation Shea expires May 1999 [Page 5] INTERNET DRAFT November 1998 This extension MUST only be used if both L2TP peers have signaled support of this extension during tunnel establishment using the Extensions AVP defined in [4]. When a session is first started it is not known if a history-bound protocol will be negotiated. An implementation should therefore pick a maximum receive window size based on the assumption that a history-bound protocol will be negotiated. If the tunnel is operating over a reliable medium this is not a factor. If the tunnel is not operating over a reliable medium then an appropriately small window size should be chosen (recommend 4?). When an LNS detects a change in the state of operation of history-bound protocols over the tunneled session it MUST send an SU to the LAC. This allows the LAC to make adjustments to its maximum receive window size, even if the LNS does not make a change itself. Upon reception of the SU with Receive Window Size AVP, the receiver of the SU MUST begin operating under the rules for Receive Window Size AVP values received during data session setup. If the value of the Receive Window Size AVP in the SU is greater than the value of the last Receive Window Size AVP received, there is no further action required by the receiver of the SU other than changing its maximum send window accordingly. If the value of the Receive Window Size AVP in the SU is less than the value of the last Receive Window Size AVP received, then the receveiver of the SU must take special action. In this case, the receiver of the SU must change its maximum send window accordingly, consider any currently unacknowledged packets as acknowledged, and send an R Bit in the next data packet sent to the peer. This prevents the data session from unnecessarily hanging when the window size is adjusted down. If for a particular data session a peer does not send the Receive Window AVP during session establishment, the Receive Window AVP MUST NOT be sent in a subsequent SU message. 5. Security Considerations Security is not addressed in this document. References [1] A. Valencia, et al, "Layer Two Tunneling Protocol", Work In Shea expires May 1999 [Page 6] INTERNET DRAFT November 1998 Progress: draft-ietf-pppext-l2tp-12.txt, October 1998 [2] D. Rand, "PPP Reliable Transmission". RFC 1663 [3] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990 [4] R. Shea, "Framework for L2TP Message Extensions", Work In Progress: draft-ietf-pppext-l2tpmsgext-00.txt, November 1998 Author's Address Richard Shea Nortel Networks 125 Nagog Park Acton, Massachusetts 01720 rshea@BayNetworks.com Shea expires May 1999 [Page 7] INTERNET DRAFT November 1998