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

["Henderson, Thomas R" <[e-mail]>]

> -----Original Message-----
> From: Kacheong Poon [mailto:[e-mail]]
> 
> 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.

I disagree that implementors will not arrive at that solution (especially
since it appears that someone already has).  Section 5, step (1) states
explicitly that the "loss recovery phase"  is terminated when a cumulative
ACK is received covering RecoveryPoint.  Section 5.1 does not say anything
about resetting RecoveryPoint after a timeout.  Therefore, I would interpret
the draft as implicitly stating that "loss recovery phase" continues after a
timeout and that the pipe algorithm should continue to be applied.

The question remains as to what is the right behavior after a timeout-- once
this is decided, I think that Section 5.1 needs to be amended to reflect
this.  I gather that the authors believe that "pipe" should not be used
after a timeout to limit the sender's ability to transmit.  For starters,
this could be explicitly stated in Section 5.1.  However, the question of
what to do about "RecoveryPoint" is trickier.  Here's why:  

When SACK information is not available, it is possible for the sender, after
a timeout, to retransmit data that is already sitting in the receiver
buffer.  This will trigger more dupacks and can lead to what is called a
"false fast retransmission" in NewReno.  For this reason, NewReno introduced
the "send_high" variable and discussed in Section 5 of RFC 2582 how to avoid
this by suppressing a re-entrance into fast retransmit after a timeout.
Implicitly, what this is saying is that, without SACK information, dupacks
after a timeout are more likely an indication of data sitting in the
receiver buffer than another loss.  

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).

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
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."

Tom  

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