[tcpm] RFC 2581 bis draft update

[Ethan Blanton <eblanton at cs.ohiou.edu>]

Hi folks,

We missed the IETF cutoff, but a new revision of 2581bis is available
for review.  We believe that it addresses the remaining comments from
WGLC, and would appreciate if people could look it over.  In order to
ease review, please find attached a summary of the major comments and
corresponding changes which went into this revision.

A copy of the draft is available at:

http://www.cs.purdue.edu/homes/eblanton/ietf/draft-ietf-tcpm-rfc2581bis-04a.txt

Thanks,
Ethan

Alfred Hönes:

Clarify Section 6, with respect to language unchaned from 2581 which
uses phrases like "this document" where it should say "[RFC2581]", etc.

    Done.


Gorry Fairhurst:

I think the document should also refer to PLPMTUD as a valid
IETF-specified way to choose a segment size.

    Section 2, the definition of SMSS now references RFC 4821.

The wording in the draft is not clear whether [RMSS] is an upper bound
to the SMSS, or just one of many ways to discover a sensible SMSS.

    The wording of 2581bis is taken directly from RFC 2581.  It is not
    clear, but changing it to be stricter seems to be a change in
    behavior, and the looser interpretation (that it is merely a way
    to discover a sensible SMSS) seems to be allowed by the current
    text.  Gorry agrees.

Is the default RMSS still 536 bytes also for IPv6, since [RFC1122]
does not apply in this context to IPv6.

    Further iteration with Gorry indicated that the existing text is
    probably okay; changes may be needed to other documents.

The document speaks only of loss, but I'm assuming that this applies
equally to ECN. If that is so, perhaps we should explicitly say so
up-front.

    Section 3 has been clarified to explicitly note RFC 3168.


Markku Kojo:

Looking into the Linux TCP behavior (that differs from what the draft
specifies) seems to reveal an issue with the draft in its usage of
FlightSize as a bad estimate for the amount of outstanding data in the
*network* and consequently inappropriate adjustment of ssthresh (and
cwnd). That is, replacing cwnd with FlightSize in equation 4 seem to
have resulted in similar kind of problems as there were earlier when
cwnd was used in the equation: [FlightSize is inflated].

    Step 2 in Section 3.2 has been modified to include the following
    text:

        When [RFC3042] is in use, additional data sent in limited
        transmit MUST NOT be included in this calculation.

    Algorithmic solutions to the problem require an additional state
    variable in the algorithms as defined.  Rather than forge down this
    route, we choose to make implementors aware of the problem and let
    them deal with it as they see fit.  Note that this problem may be a
    non-issue on some stacks (particularly those using RFC 3517 or
    similar).

It might be useful also note that the purpose of the slow start
algorithm is to (re)start the ack clock (in addition to determining the
available capacity).

    Done.

"On the other hand, when a TCP sender detects segment loss using              
 the retransmission timer and the given segment has already been
 retransmitted at least once, the value of ssthresh is held constant."
                                                                                
Should be clarified that this applies only when the retransmission timer
expires again for the same segment, not when retransmission timer
expires for a fast retransmitted segment.

    Done.

It would be useful to note that allowing a TCP sender to send a new data
segment on the 1st and 2nd dupack is in violation to the definition of
cwnd in Section 2[.]

    No change.  While this is true, the text is pretty clear about
    exactly what you do, and when.

"Loss in two successive windows of data, or the loss of a                     
 retransmission, should be taken as two indications of congestion and,
 therefore, cwnd (and ssthresh) MUST be lowered twice in this case."
                                                                                
Lowering ssthresh twice on the loss of a retransmission triggered by an
RTO would be in contradiction with what is said in Section 3.1 (see item
2 above). Should clarify that this is valid only with the loss of a fast
retransmit (or the loss of a retransmission in fast recovery with an
advanced loss recovery alg such as NewReno or SACK-based fast recovery)

    With the clarification above, this is no longer necessary.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www.ietf.org/mailman/listinfo/tcpm