Subject: Re: [Tsvwg] Eifel Detection & Loss of all ACKs

From: Sally Floyd <[email-masked]>
Date: Thu, 29 Aug 2002 16:57:37 -0700

>I admit that it sounds odd to call a timeout that occured because an entire 
>window of ACKs got lost *while (at least) the oldest outstanding segment 
>was not lost* a spurious timeout. This is even more so since such a timeout 
>is unavoidable. However, also in this situation does the standard TCP 
>sender "misbehave" since it does a go-back-N in slow start, potentially 
>breaking packet conservation. I.e., it retransmits all outstanding segments 
>at double ACK-clock speed without knowing whether those segments were lost 
>or not.

Hmmm.  I would have thought that if none of the data packets were lost,
but all of the acks were lost, then the sender would wait for a timeout,
retransmit one packet, receive an ACK acknowledging the entire
previous window of data, and proceed happily on its way (with a halved
congestion window).  Only having unnecessarily retransmitted one packet.

And if one or more of the data packets were lost (but not the oldest
outstanding segment), and all of the acks were lost, but the sender
used SACK, then it would wait for a timeout, retransmit one packet,
receive an ACK acknowleding part of the previous window, along with
any appropriate SACK blocks.  So with SACK, the sender still would
only unnecessarily retransmit one packet following the loss of an
entire window of ACKs.

Yes?  Am I forgetting something?

So it seems to me that there isn't any Go-Back-N behavior in this
case, and the question is simply whether it is or isn't OK for the
sender to "undo" its halving of the congestion window.  My vote
would be that it would be preferable for the sender to be required
to continue to halve its congestion window when all of the ACKs in
a window of data are lost, but I don't have any evidence about
whether this is a trivial and rare corner case, or something that
it is in fact important to be careful about.  It seems *conceivable*
to me that there could be cases with persistent high loss rates on
the return path where this could actually matter...

I will also look at Pasi's report at
"http://www.cs.Helsinki.FI/group/iwtcp/papers/f-rto.ps"
to see if it sheds any light on this.

- Sally
http://www.icir.org/floyd/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 30 Aug 2002 10:46:20 +0200

>Yes?  Am I forgetting something?

No, you're not. I was probably too much asleep when I wrote that mail 
yesterday. Of course, it works the way you wrote it, and I was simply wrong.

Sorry, if that has caused headaches for some people.

>case,

True.

>and the question is simply whether it is or isn't OK for the
>sender to "undo" its halving of the congestion window.

Yes, that's the question.

>My vote

Fine.

But, if we wanted to treat that case separately, we can't rely solely on 
timestamps. Please, see section 3.3 of the current draft. We could only 
make it work for non-RFC1323-compliant TCP receivers that follow the 
RFC1323 update attempt by Bob Braden: 
http://www.kohala.com/start/tcplw-extensions.txt. But that doesn't seem 
like a good way to go ...

Otherwise, I only see the alternative to mandate DSACK to be used with 
Eifel detection to treat that case separately. And, I wouldn't feel so 
comfortable with that because it requires additional TCP receiver support 
(implementing RFC2883). Whereas if both sides support RFC1323, Eifel 
detection/response is a sender-side-only modification.

Also, I still believe that we're discussing an extremely exotic scenario: 
"the segment for which the timeout occured did in fact arrive at the TCP 
receiver & loss of all ACKs in that case" + that event needs to occur 
sufficiently frequent over the lifetime of a TCP connection for this to 
become a real problem.

I would argue that any TCP that has to run across a network exhibiting such 
characteristics and the network itself has some serious problems; with or 
without Eifel.

So, at this point I believe that we're discussing a non-(real-world-)issue.

///Reiner

PS: BTW, if there was the RXT flag, we wouldn't have this issue (although 
that also requires TCP receiver changes) ...