Subject: [Tsvwg] Eifel Detection: Open Issues so far ...

From: Reiner Ludwig <[email-masked]>
Date: Mon, 19 Aug 2002 15:14:21 +0200

Hi Pasi,

I think that most has been said in the discussion you and I had. I would 
just like to conclude that we have different views on two fundamental 
issues. So, maybe we can agree that we disagree on those two issues, and 
then let others speak ...

1. Packet Conservation vs. TCP's performance:
Your view:
"Don't harm the standard TCP performance under any condition."
Our view:
The current TCP breaks packet conservation after a spurious timeout 
(go-back-N loss recovery). If no packets were in fact lost although the TCP 
sender timed out, the TCP sender sends 50 percent more packets into the 
network than allowed by the congestion window. Any proposal that addresses 
spurious timeouts needs to fix this misbehavior. Yes, fixing this means 
that performance is reduced compared to standard TCP for the case where a 
spurious timeout coincides with multiple losses from the outstanding window.
=> you believe that performance is more important; we believe that packet 
conservation is more important.

2. Reverting to Previous Congestion Control State
Your view:
"Undoing congestion window is too brave action after spurious RTO caused by 
delay, since the packets have queued up to some node during the delay."
Our view:
If the sender *reliably* detects that it had taken the wrong decision in 
the past (triggering congestion control), it may revert to previous 
congestion control state. Note, that also with Eifel the TCP sender will 
re-enter loss recovery again as soon as the next packet loss is indicated 
(timeout or 3rd DUPACK).
=> we believe that cwnd/ssthresh should only be reduced in response to real 
packet losses; you believe that it should also remain reduced after longer 
delays on the path.

Does this correctly reflect your views?

///Reiner

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

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 19 Aug 2002 17:21:35 +0300

Hi,

On Monday 19 August 2002 16:14, ext Reiner Ludwig wrote:

> I think that most has been said in the discussion you and I had. I
> would just like to conclude that we have different views on two
> fundamental issues. So, maybe we can agree that we disagree on those
> two issues, and then let others speak ...

I agree on this. :-) So, I'll give the conclusion on my part.

> (go-back-N loss recovery). If no packets were in fact lost although
> the TCP sender timed out, the TCP sender sends 50 percent more
> packets into the network than allowed by the congestion window. Any
> proposal that addresses spurious timeouts needs to fix this
> misbehavior. Yes, fixing this means that performance is reduced
> compared to standard TCP for the case where a spurious timeout
> coincides with multiple losses from the outstanding window. => you
> believe that performance is more important; we believe that packet

You got it right. By sticking to the packet conservation principle 
after RTO in situations where "pipe" happens to be overestimated (e.g. 
due to applying Eifel with burst loss) you will likely cause bad 
performance, either due to additional RTOs or by having a long period 
of time when you have only one or two packets in flight at a time for 
several round-trips. So why not tell about these related performance 
trade-offs in the draft?

And it still confuses me to speak about spurious timeout in case where 
there has been a massive data loss and RTO is the only way to move 
onward...

> "Undoing congestion window is too brave action after spurious RTO
> caused by delay, since the packets have queued up to some node during
> the delay." Our view:
> If the sender *reliably* detects that it had taken the wrong decision
> in the past (triggering congestion control), it may revert to
> previous congestion control state. Note, that also with Eifel the TCP
> sender will re-enter loss recovery again as soon as the next packet
> loss is indicated (timeout or 3rd DUPACK).
> => we believe that cwnd/ssthresh should only be reduced in response
> to real packet losses; you believe that it should also remain reduced
> after longer delays on the path.
>

Yes, although I don't know what exactly should be done with the 
congestion control state. Halving cwnd on spurious RTO is conservative 
enough, fully reverting it is maybe too aggressive, so perhaps setting 
it to 3/4 of the earlier value or applying something like congestion 
window validation would be feasible action, I don't know.

- Pasi

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 20 Aug 2002 12:02:12 +0200

two small comments ...

>several round-trips. So why not tell about these related performance

We have done so in 
http://search.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-00.txt:
   "In fact, we recommend that the Eifel response algorithm is
    implemented together with one of those advanced loss recovery schemes;
    ideally a SACK-based alternative. In an environment where spurious
    timeouts and back-to-back packet losses often coincide, we have found
    that TCP's performance can even suffer if the Eifel response
    algorithm is operated without an advanced loss recovery scheme
    [GL02]."

>there has been a massive data loss and RTO is the only way to move

You got us wrong. We do not speak of a spurious timeout in case of *massive 
data loss*.

However, we do speak of a spurious timeout when all ACKs have been lost 
while the TCP sender gets the indication that at least the original 
transmit of the oldest outstanding segment (and potentially the entire 
flight) has arrived at the TCP receiver. I.e., at that point in time the 
TCP sender has no reason to believe that there had been congestion in the 
data path. Remember that the current congestion control only operates on 
the data path. Congestion control for the ACK path is a different thing 
that we might need in the future as others have indicated in previous work.

///Reiner