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

From: Sally Floyd <[email-masked]>
Date: Thu, 05 Sep 2002 16:37:43 -0700

...
>If we left CWND halved then this would be some implicit form of congestion 
>control for the ACK path, right?

Yep.

>The scheme you propose to detect the case of all the ACKs being lost works 
>if none of the original transmits was lost. However, if in addition some 
>but not the oldest outstanding data segment were lost, I still think that 
>we would need the SACK and/or the DSACK option ...

(Though in the long term SACK and DSACK will be ubiquitous, I assume...)

...
>> >So, at this point I believe that we're discussing a non-(real-world-)issue.
>>
>>My own opinion would be that the issue of severe congestion on
>>reverse paths is a real-world issue that can not be ignored.
>
>Severe congestion on the reverse path, and frequently loosing a window 
>worth of ACKs (*and* not loosing the oldest outstanding segment) are 
>different things, in my opinion.

If the TCP sender had a way to know *for sure* that the loss of a
window of ACKs was due to something other than congestion, that
would seems fine to me.  In the absence of such knowledge, then my
own view would be that the loss of a window of ACKs should be assumed
to be due to congestion on the reverse path, and should be accompanied
by a halving of the congestion window.

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

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 06 Sep 2002 14:30:59 +0200

At 01:37 06.09.2002, Sally Floyd wrote:
>would seems fine to me.

I can't imagine how the TCP sender could know that *for sure* without 
explicit knowledge from the network.

>In the absence of such knowledge, then my

If the WG shares your view, we need to mandate the use of SACK for Eifel 
since with SACK we can distinguish that case. I would then need to revise 
the Eifel detection draft, but that shouldn't be a problem.

This seems to be the only open issue with the Eifel *detection* draft (the 
Eifel *response* draft certainly is a different thing). So, maybe we can 
hear other people's view on this.

Just to be sure, we're discussing the same thing:
It is *not* about the simple case where all ACKs are lost. It is about the 
much more specific case where all ACKs are lost *and* the oldest 
outstanding segment has arrived at the TCP receiver. *Only* in that very 
special case will the current Eifel detection algorithm declare that loss 
recovery was unnecessarily entered. And, Eifel response would revert to the 
previous congestion control state.

My own opinion is still that this case is pathological enough to be 
ignored. And, it does not justify that the Eifel algorithm be made 
dependent on the use of the SACK option.

Clearly, if the oldest outstanding segment and all ACKs were lost, Eifel 
would not kick in, anyway.

Looking forward to hearing other opinions.

///Reiner