[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01                                                         
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