RE: [tcpm] WGLC: 2581bis
"Agarwal, Anil" <Anil.Agarwal@viasat.com> Thu, 29 November 2007 12:35 UTC
Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixic9-0005W3-J9; Thu, 29 Nov 2007 07:35:33 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ixic8-0005RE-CW for tcpm-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:35:32 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixic7-0005Pq-UF for tcpm@ietf.org; Thu, 29 Nov 2007 07:35:31 -0500
Received: from harrier.viasat.com ([12.198.241.131] helo=VGAEXCH02.hq.corp.viasat.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixic7-0004wS-7C for tcpm@ietf.org; Thu, 29 Nov 2007 07:35:31 -0500
Received: from VGAEXCH01.hq.corp.viasat.com ([172.31.1.20]) by VGAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 07:35:56 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [tcpm] WGLC: 2581bis
Date: Thu, 29 Nov 2007 07:36:18 -0500
Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B065A70706@VGAEXCH01.hq.corp.viasat.com>
In-Reply-To: <20071127004720.GD3385@hut.isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] WGLC: 2581bis
Thread-Index: Acgwj0ZfCkaNAx6eRWqVgc6wso8SxAB8f9xA
From: "Agarwal, Anil" <Anil.Agarwal@viasat.com>
To: Ted Faber <faber@ISI.EDU>, tcpm@ietf.org, mallman@icir.org
X-OriginalArrivalTime: 29 Nov 2007 12:35:56.0281 (UTC) FILETIME=[63483E90:01C83284]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc:
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org
Mark, Ted, Here are some belated comments on draft-ietf-tcpm-rfc2581bis-03.txt. Most of these suggestions seek to add clarity to and remove ambiguities from the rfc. 1. Section 2. "FLIGHT SIZE: The amount of data that has been sent but not yet acknowledged." Would be useful to clarify that Flight Size is not reduced by SACK info. Flight Size = snd.max - snd.una 2. Section 2. "DUPLICATE ACKNOWLEDGMENT: ... Alternatively, a TCP that utilizes selective acknowledgments [RFC2018,RFC2883] can determine an incoming ACK is a "duplicate" if the ACK contains previously unknown SACK information." This statement can be misinterpreted that this rule is an alternative to the previous 5 rules. Perhaps, it should be stated that this is an alternative to rule (e) only? 3. Section 3.1 "When larger initial windows are implemented along with Path MTU Discovery [RFC1191], and the MSS being used is found to be too large ..." Clarify, what "larger initial windows" means. Perhaps, this statement should apply to any IW, large or small. Alternatively, cwnd should be reduced by the ratio mentioned, but need not be reduced below the value of IW according to the equations above as applied to the new segment size. 4. Section 3.1 "The initial value of ssthresh SHOULD be set arbitrarily high (e.g., to the size of the largest possible advertised window),..." Clarify what "largest possible advertised window" means for a TCP transmitter, which has not sent or received any "advertisements" yet. 5. Section 3.1 "During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that acknowledges new data." Would be useful to clarify that ACK with old ack value but new SACK info., does not qualify for above. The ACK should advance snd.una. 6. Section 3.1 After the slow start description, it might be useful to add a note: During slow-start, cwnd increases approximately by 50% every RTT when receiver sends delayed ACKs. Lost ACK segments cause a reduction in cwnd growth rate. 7. Section 3.1 "During congestion avoidance, .. The basic guidelines for incrementing cwnd during congestion avoidance are: * MAY increment cwnd by SMSS bytes * SHOULD increment cwnd per equation (2) * MUST NOT increment cwnd by more than SMSS bytes" Would be useful to clarify that these are per RTT, not per ACK. Add note that for 2nd bullet, N in equation (2) refers to bytes acknowledged in last RTT. 8. Section 3.1 "The RECOMMENDED way to increase cwnd during congestion avoidance is to count the number of bytes that have been acknowledged by ACKs for new data. (A drawback of this implementation is that it requires maintaining an additional state variable.) When the number of bytes acknowledged reaches cwnd, then cwnd can be incremented by up to SMSS bytes." Could use some more precision about when to start and re-start counting. 9. Section 3.1 "We note that [RFC3465] allows for cwnd increases of more than SMSS bytes for incoming acknowledgments during slow start on an experimental basis, however such behavior is not allowed as part of the standard." Move this para before previous para? 10. Section 3.1 "Implementation Note: Since integer arithmetic is usually used in TCP implementations, the formula given in equation 3 can fail to increase cwnd when the congestion window is larger than SMSS*SMSS. If the above formula yields 0, the result SHOULD be rounded up to 1 byte." Might be useful to add a note that this violates the rule "MUST NOT increment cwnd by more than SMSS bytes (per RTT)", but is allowed by the rfc. 11. Section 3.2 "On the first and second duplicate ACKs received at a sender, a TCP SHOULD send a segment of previously unsent data per [RFC3042] provided that the receiver's advertised window allows, the total FlightSize would remain less than or equal to cwnd plus 2*SMSS ..." Sounds like the cwnd plus 2*MSS rule applies even after the first duplicate ACK, which seems incorrect. 12. Section 3.2 "The lost segment MUST be retransmitted and cwnd set to ssthresh plus 3*SMSS." ... Would be useful to clarify that a single segment with send sequence number = snd.una must be retransmitted. 13. Section 3.2 "Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window." This rule needs a MUST or a SHOULD. Add a note that the sender may not transmit a segment if cwnd becomes too large and buffer size limitations prevent it from accepting new user data. 14. Section 4.1 Would be useful to mention that this technique is not just for avoiding traffic bursts, but also that cwnd, which reflects network congestion state, is inaccurate after a long idle period and hence should be re-estimated using slow-start. 15. Section 4.1 The description in this section does not completely eliminate packet bursts. As well all know, large transmit bursts can occur for other reasons - e.g., lost ACKs, sender not using its full cwnd for some period of time, sender going quiet for less than one RTT, receiver sending a large window update. Might be beneficial to refer to other useful techniques for reducing burst transmits, such as pacing and note that this as an area that may benefit from additional attention, experimentation and specification. Regards, Anil Anil Agarwal ViaSat Inc. Germantown, MD 20876 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm
- [tcpm] WGLC: 2581bis Ted Faber
- RE: [tcpm] WGLC: 2581bis Agarwal, Anil
- Re: [tcpm] Re: WGLC: comments on 2581bis Gorry Fairhurst
- [tcpm] WGLC: comments on 2581bis Gorry Fairhurst
- [tcpm] Re: WGLC: comments on 2581bis Mark Allman
- Re: [tcpm] Re: WGLC: comments on 2581bis John Heffner
- Re: [tcpm] WGLC: 2581bis Ted Faber
- Re: [tcpm] WGLC: 2581bis Alfred Hönes
- Re: [tcpm] WGLC: 2581bis Markku Kojo
- Re: [tcpm] WGLC: 2581bis Ted Faber