RE: [tcpm] WGLC: 2581bis

["Agarwal, Anil" <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm