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

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

> It appears to me that by this you mean that the packets are actually
> *lost*, and not just delayed for a ridiculous period of time.
> 

Yes.

> > - at this point, correct behavior is somewhat ambiguous 
> (underspecified).
> > Murakami et al., who cite draft-allman-tcp-sack-07.txt, 
> describe a TCP
> > sender that waits again for timeouts for each subsequent 
> retransmission
> > (ever increasing the backoff), resulting in recoveries that 
> can last for
> > tens of minutes.  If instead the TCP sender always permits 
> at least one
> > transmission upon receipt of an ACK, it may instead send the next
> > retransmission in response to this ACK, without waiting for 
> a timeout.  But
> > the bottom line is that it seems that at most one segment 
> can be recovered
> > per RTT if pipe control is used and pipe > cwnd.
> 
> This appears to be incorrect.  At this point the TCP sender is not
> being governed by draft-allman-tcp-sack-11, but by traditional slow
> start with the added condition that "Update () MAY continue to be used
> appropriately upon receipt of ACKs".  Because of this, the values of
> LeftNetwork (), HighData, etc. are not relevant.
> 
> There may in fact be some issues if there is a second loss (after the
> RTO) losing a segment below HighData.  I will look at this.
> 

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

I strongly prefer to give explicit guidance as to what should happen after a
timeout.  The text I proposed for section 4 is one way to do this.  Or
section 5.1 could be changed.

A possible source of confusion might be your use of "loss recovery phase" to
mean "fast recovery phase", since one could consider retransmissions after a
timeout also as "loss recovery".  Perhaps this should be in the definition
section 2.

> > The question of whether HighData should be changed upon a timeout is
> > interesting.  A cautious approach would be to not reset it 
> so as to avoid
> > false fast retransmissions that might arise from dupacks 
> that are generated
> > due to previously received segments that the sender 
> retransmits-- this would
> > be in line with NewReno principles.  However, if the 
> receiver is properly
> > sending SACK blocks, unnecessary retransmissions should be 
> avoided, and
> > dupacks would probably indicate an additional segment loss 
> (or possibly that
> > the receiver has discarded SACKed data).   
> 
> My personal feeling on this matter (and, I think, shared by my
> co-authors) is that an RTO is a Bad Thing.  We are working under the
> assumption that if our SACK-aware fast recovery was not sufficient
> something very wrong has happened (small windows do break this
> assumption in some cases) and all possible caution is merited.
> 

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.

Tom 

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