idnits 2.17.1 draft-ietf-pppext-l2tpdwin-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 73: '... o MUST, SHALL, or MANDATORY --...' RFC 2119 keyword, line 76: '... o SHOULD or RECOMMEND -- This ...' RFC 2119 keyword, line 79: '... o MAY or OPTIONAL -- This item...' RFC 2119 keyword, line 108: '...P implementation SHOULD start the sess...' RFC 2119 keyword, line 114: '... RECOMMENDED that the bandwidth and ...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1998) is 9447 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-11 Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group Richard Shea 2 INTERNET DRAFT Bay Networks 3 Category: Internet Draft 4 Title: draft-ietf-pppext-l2tpdwin-00.txt 5 Date: June 1998 7 L2TP Dynamic Data Window Adjustment 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 25 munnari.oz.au. 27 Abstract 29 The Layer Two Tunneling Protocol (L2TP) defines the specification 30 of congestion window sizes for data sessions. In addition, an LNS 31 is given the capability to turn off sequence number processing for 32 a data session, provided the LAC did not include the Sequencing 33 Required AVP during session setup. This document specifies a 34 mechanism whereby an L2TP peer can dynamically change the window 35 size values being used for a data session, in order to provide the 36 flexibility to operate with smaller window sizes when history-bound 37 protocols are operating over a session, and larger window sizes 38 when no history-bound protocols are operating over a session. 40 1. Introduction 42 In the L2TP protocol sequence numbers are used for preserving 43 packet order, detecting packet loss, and congestion control. An 44 affective window size value for congestion control is influenced in 45 opposite directions by two things. First, in the case where 46 protocols with history are being carried, the window size must be 47 small enough so that forced packet loss is not excessive in the 48 case of a real packet drop where resynchronization is necessary. 49 At the same time, the larger the delay between the LAC and LNS, the 50 larger the window size should be so that the available bandwidth 51 between the LAC and LNS is not underutilized. 53 Unfortunately, the L2TP protocol specifies that the window sizes 54 for a session are determined when the session is established, at a 55 time before it is known whether or not protocol with history will 56 be operating over the session. 58 It is important for L2TP to provide the flexibility to maximize 59 performance for the cases where history-bound protocols are 60 operating over a data session for a tunnel which is operating over 61 a lossy network or where no history-bound protocols are operating 62 over a data session being tunneled over a high-delay path. Because 63 the knowledge of whether history-bound protocols will be operating 64 over a data session is not known at the time of session setup, a 65 mechanism for dynamically updating the data session window sizes is 66 needed. 68 1.1 Conventions 70 The following language conventions are used in the items of 71 specification in this document: 73 o MUST, SHALL, or MANDATORY -- This item is an absolute 74 requirement of the specification. 76 o SHOULD or RECOMMEND -- This item should generally be followed 77 for all but exceptional circumstances. 79 o MAY or OPTIONAL -- This item is truly optional and may be 80 followed or ignored according to the needs of the implementor. 82 1.2 Terminology 84 This draft assumes the reader is knowledgable about terms found in 85 [1]. In addition, the following terms are used in this document: 87 History-Bound Protocol 89 Any protocol where secondary information is passed along with 90 data in the protocol packets where synchronization of such 91 secondary information between the two peers is necessary, and 92 where this synchronization takes place across packet 93 boundaries. This is a typical property of compression and 94 sometimes encryption protocols, although most protocols also 95 have an operational mode where synchronization across packet 96 boundaries is not necessary. 98 2. Protocol overview 100 The current practice for L2TP is for window sizes to be indicated 101 at the time of session setup, and for these window sizes to remain 102 the same for the life of the session. 104 This document describes an operational addition to L2TP to allow 105 data session window sizes to change during the life of a data 106 session. 108 An L2TP implementation SHOULD start the session with a window size 109 which is appropriate for maximizing performance assuming that a 110 history-bound protocol will not be used during the life of the 111 session (this includes the option of no flow control). Ideally 112 this is done with knowledge of the bandwidth and delay 113 characteristics of the path between the LAC and LNS. It is 114 RECOMMENDED that the bandwidth and delay for the path between an 115 LNS and LAC be configurable. 117 When a history-bound protocol is negotiated within the data 118 session, the window size MUST be changed to a value which is 119 appropriate for maximizing performance for history-bound 120 protocols. If the data session is tunneled over a path which is 121 known to be reliable, or PPP reliable mode ([2]) has been 122 negotiated for the data session the window size MUST NOT be changed 123 due to detected negotiation of a history-bound protocol. This 124 document recommends a window size between 2 and 4 for data sessions 125 where a history-bound protocol is operating and reliability is not 126 provided by PPP or for the path between the LAC and LNS. 128 An implementation MAY start with a window size appropriate for a 129 data session where a history-bound protocol is operating, and later 130 increase the window size based on history-bound protocols not being 131 in operation over the data session. 133 An implementation MAY also change the window size to provide larger 134 window sizes for some data session and smaller window sizes for 135 other data sessions, based on other criteria. This may be decided, 136 for example, based on the authentication credentials for each 137 session. 139 3. Protocol additions 141 This document specifies no new AVPs or message types, but does 142 specify the use of an existing AVP in a message that it currently 143 is not found in. 145 The Receive Window Size AVP is used to communicate the changing of 146 window size after a session has been established. This is done by 147 including the Receive Window Size AVP in the Set-Link-Info (SLI) 148 message. 150 The format for this is given below. 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | L2TP Control Message Header | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Set-Link-Info | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | ACCM | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Receive Window Size | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 The format of the L2TP control message header, message type AVP, 163 and ACCM AVP in the Set-Link-Info message are given in [1]. 165 Receive Window Size 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |1|0|0|0|0|0| 8 | 0 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | 10 | Size | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Receive Window Size AVP encodes the window size being advertised 176 for this call. Attribute is 10, indicating Receive Window Size, 177 and is marked optional for purposes of compatibility with peers who 178 do not support this document. This AVP is optional. The Size 179 value indicates the number of received data packets the sender of 180 the SLI will buffer for this call, which is also the maximum number 181 of data packets the receiver of the SLI should send before waiting 182 for an acknowledgment. 184 Upon reception of the SLI with Receive Window Size AVP, the 185 receiver of the SLI MUST begin operating under the rules for 186 Receive Window Size AVP values received during data session setup. 187 The receiver of the Receive Window Size AVP in the SLI SHOULD also 188 send their own SLI with Receive Window Size AVP present based on 189 the value that was received. A Receive Window Size AVP value sent 190 in an SLI message prompted by the reception of Receive Window Size 191 AVP in an SLI should reflect the same nature of change for the 192 local receive window size change as was caused by the change in the 193 peer's receive window size. 195 4. Security Considerations 197 Security is not addressed in this document. 199 References 201 [1] A. Valencia, et al, "Layer Two Tunneling Protocol", Work In 202 Progress: draft-ietf-pppext-l2tp-11.txt, May 1998 204 [2] D. Rand, "PPP Reliable Transmission". RFC 1663 206 Author's Address 208 Richard Shea 209 Bay Networks 210 125 Nagog Park 211 Acton, Massachusetts 01720 212 rshea@BayNetworks.com