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

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 9 Jul 2002 09:47:49 -0700

> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 15 Jul 2002 04:17:53 -0500 (CDT)

Included message from "Henderson, Thomas R" <[email-masked]>:

>----

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.

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 15 Jul 2002 10:28:19 -0700

> -----Original Message-----
> From: Kacheong Poon [mailto:[email-masked]]
> 

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

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 15 Jul 2002 23:02:21 -0500 (CDT)

>fast retransmissions occur (Ethan has pointed out to me this problem in a

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.

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

>recovery phases SHOULD NOT be initiated until a cumulative ACK is received

If this really makes things clearer, then add it.

							K. Poon.