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

[Kacheong Poon <[e-mail]>]

Included message from "Henderson, Thomas R" <[e-mail]>:

>----
>Now consider the case in which the receiver is sending SACK blocks.  After a
>timeout, the sender SHOULD expunge SACK information.  The sender MAY then
>use subsequently received SACK information to avoid unnecessary
>retransmissions.  However, will the receiver provide enough information?  It
>depends on how many SACK blocks exist between HighRxt and HighData.  If
>there are three or less, then enough SACK information should be replenished,
>and any subsequent dupacks are more likely to indicate the loss of a
>retransmitted segment.  If there are more than three, however, since the
>receiver is instructed by RFC 2018 to repeat the most recent SACK blocks and
>not the oldest SACK blocks, we could again be in a situation where false
>fast retransmissions occur (Ethan has pointed out to me this problem in a
>separate email).

Actually, it really depends on the algorithm in handling the use of
SACK info after a timeout.  For example, the sender can keep a copy
of the SACK info before the timeout.  After the timeout and slow start
retransmission is taking place, it can compare the old copy with the
newly received SACK info (so an implementation needs to maintain 2 sets
of SACK info after a timeout and before all lost segments have been
recovered) .  It can infer a lot of things, including retransmitted 
segments being dropped again, from that regardless of how many holes 
there are in the receiver.  And it can be made clever enough to handle
the case when out of order received segments are discarded in the
receiver such that old SACK info does not provide a correct picture.

>If we maintain RecoveryPoint after a timeout, we then essentially take the
>position that retransmission losses must be recovered via timeout, even if
>there might be indications from SACK information that an additional loss
>occurred.  This seems to be what is preferred based on the comments I've
>received.  It probably is simpler to implement.  But in either case, it

Yes, I agree that TCP should be conservative and not do "clever
recovery" after a timeout, not because it is simpler to implement.
The network must be pretty congested (assuming that this is the 
reason why segments are dropped) if retransmitted segments are again
lost after the timeout.

>should be stated more clearly in Section 5.1.  Here is a text proposal for
>the end of 5.1 (continuation of existing last paragraph):
>
>"The pipe variable SHOULD NOT be used to limit transmissions after a
>retransmission timeout, even though Update() and NextSeg() can be used to
>intelligently select segments for transmission.  Furthermore, RecoveryPoint
>SHOULD NOT be changed upon a retransmission timeout, and additional fast
>recovery phases SHOULD NOT be initiated until a cumulative ACK is received
>for RecoveryPoint."

If this really makes things clearer, then add it.

>----


							K. Poon.


_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg