RE: [Tsvwg] problem with draft-allman-tcp-sack-11.txt

Included message from "Henderson, Thomas R" <thomas.r.henderson@boeing.com>:

>----
>I agree that the behavior described above is incorrect, but one could arrive
>at that kind of implementation the way things are worded now (proof by
>example, in the paper cited).  You mention that "Update() MAY continue to be
>used..." after timeout, but this text seems to be referring mainly to the
>ability of the sender to capitalize on new SACK information to prevent
>unnecessary retransmission.  I don't think it is clear that pipe control is
>off after a timeout, nor is it clear when to turn it back on (I think that
>you want to have it on during fast recovery phase, but perhaps that should
>be stated).

Actually, I don't think implementors are likely to arrive at the
above suggested behavior.  The reason is simply that SACK info should 
probably be discarded after a TCP timeout.  If I remember correctly,
this is stated in the original SACK RFC (forgot if it is a SHOULD
or MUST).  This is to prevent from a bad situation in which the 
receiver discards SACK'ed data.  This is an unlikely event and is 
discouraged.  But it can happen because the receiver is running out 
of memory and has to discard SACK'ed data, otherwise it will not be 
able to receive the in sequence retransmitted segment, causing a 
deadlock.

>But are you then suggesting that you prefer the option I described above of
>resetting HighData (that is, allowing for a fast retransmit after timeout if
>you get dupacks before you have finished retransmitting past HighData)?
>That option would lower the possibility of an additional timeout, at the
>cost of possibly reducing cwnd due to false fast retransmissions.

Given the fact that the sender has to discard SACK info received
before the timeout, I guess it may not be a good idea to reset 
HighData.  I agree with Ethan that the conservative approach is
just to do a normal slow start after a timeout.

>----

							K. Poon.

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg