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

From: Reiner Ludwig <[email-masked]>
Date: Fri, 23 Aug 2002 12:51:25 +0200

I was told that the attached e-mail was dropped from [email-masked] ...

///Reiner

>Date: Wed, 21 Aug 2002 13:25:48 +0200
>To: [email-masked]
>From: Reiner Ludwig <[email-masked]>
>Subject: RE: [Tsvwg] Re: Eifel Detection: Open Issues so far ...
>Cc: [email-masked]
>
>At 01:20 21.08.2002, [email-masked] wrote:
>>         As far as I understood after reading the draft and from the 
>> mails sent lately there is a problem when both ACKs and TCP segments are lost.
>
>There is no problem that I'm aware of.
>
>Pasi only correctly pointed out that when applying Eifel 
>detection/response, performance can be less than with standard TCP in 
>situations where multiple data segments are lost from the same flight; 
>especially if no advanced loss recovery scheme, e.g., SACK-based, is 
>operated. We have pointed that out in 
>draft-ietf-tsvwg-tcp-eifel-response-00.txt (see my last mail to this 
>list), and therefore recommend applying Eifel detection/response together 
>with such advanced loss recovery schemes.
>
>This has *not* to do with a false decision of the Eifel detection 
>algorithm, but with the aggressiveness of standard TCP after a spurious 
>timeout. This has been discussed in the mail thread between Pasi and me.
>
>
>>         However, applying the Eifel algorithm we might consider that all 
>> the outstanding TCP segments are still in flight, while in reality they 
>> have been lost.
>
>That's the point! As long as the TCP sender does not know whether data 
>segments have been lost or not, it has to make the conservative decision, 
>i.e., it has to assume that all outstanding segments are still in the network.
>
>///Reiner

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

---

From: [email-masked]
Date: Wed, 28 Aug 2002 18:33:58 -0500

Hi Ludwig,

I have a few questions and comments on the Eifel detection and response algorithm. I am curious to know if anyone has done any simulation/emulation/Internet-wide-tests with the Eifel algorithm in a realistic scenario. A realistic scenario is one in which there are more than one TCP connection competing with each other and having different round trip times.

I have gone through the paper by you and Randy Katz, but I did not see any performance evaluation under any reasonable scenario (although the section 5 of paper does try to theoretically evaluate the performance benefits.)  

In addition, this paper argues that the congestion window should be restored because of "conservation of packet" principle. But conservation of packet holds only if you have received at least one ack within an RTT. Since there is no bound on the time duration for packet stalling in the network, there is no guarantee that the network will still have the same congestion state after the timeout (if the congestion states were to persist for a period more than RTO, you would never need to go to slow start in the middle of a connection). I do not believe that restoring the congestion window is a reasonable solution. Of course if you only have a single TCP connection (as in your GPRS paper), there is no problem. But if you have a single TCP connection, do you need congestion control at all?  

I will appreciate if you could provide some real-world/simulation results in a realistic scenario (with multiple TCP connections competing for resources and sharing more than one intermediary routers). I am also surprised that IETF does no require any validation results before making last calls.

Thanks
Best Regards
Yogesh

-----Original Message-----
From: ext Reiner Ludwig [mailto:[email-masked]]
Sent: Friday, August 23, 2002 5:51 AM
To: [email-masked]
Subject: Fwd: RE: [Tsvwg] Re: Eifel Detection: Open Issues so far ...

///Reiner

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 29 Aug 2002 14:27:39 +0200

Yogesh,

At 01:33 29.08.2002, [email-masked] wrote:
I am curious to know if anyone has done any 
simulation/emulation/Internet-wide-tests with the Eifel algorithm in a 
realistic scenario.

- http://www.cs.helsinki.fi/u/gurtov/papers/ew02.html
- Yavuz, M. and F. Khafizov, "TCP over Wireless Links with Variable 
Bandwidth", Proc. of IEEE Vehicular Technology Conference , September 2002.
- Also, a variant of the Eifel algorithm is part of LINUX (kernel 2.4.x), 
and experience has been made: P. Sarolahti and A. Kuznetsov. Congestion 
Control in Linux TCP. In Proceedings of Usenix 2002/Freenix Track, pp. 
49--62. Monterey, CA, USA, June 2002. available at 
http://www.cs.helsinki.fi/research/iwtcp/papers/

A realistic scenario is one in which there are more than one TCP connection 
competing with each other and having different round trip times.

I don't follow. Why is such a scenario relevant for the Eifel algorithm?

I have gone through the paper by you and Randy Katz, [...] this paper 
argues that the congestion window should be restored because of 
"conservation of packet" principle. But conservation of packet holds only 
if you have received at least one ack within an RTT.

Receiving at least ons ACK per RTT sounds like a reasonable assumption.

Since there is no bound on the time duration for packet stalling in the 
network, there is no guarantee that the network will still have the same 
congestion state after the timeout (if the congestion states were to 
persist for a period more than RTO, you would never need to go to slow 
start in the middle of a connection).

Again, I don't quite follow. Please, elaborate a bit more on this.

I do not believe that restoring the congestion window is a reasonable 
solution.

Bottom line is: congestion control is supposed to be triggered in response 
to packet loss in the data path. No RFC mandates that it should also be 
triggered because of RTT spikes, packet reordering, or packet duplication. 
So, we believe that if we can realiably detect the occurence of those 
events, the TCP sender MAY reverse congestion control state. If the sender 
does so, it should also do something about its SRTT and RTTVAR in the case 
of spurious timeouts, and about DupThresh in the other cases.

Of course if you only have a single TCP connection (as in your GPRS paper), 
there is no problem. But if you have a single TCP connection, do you need 
congestion control at all?

????

///Reiner

---

From: [email-masked]
Date: Fri, 30 Aug 2002 07:03:20 -0500

Hi,

Please see me response below:

> Sent: Thursday, August 29, 2002 7:28 AM
> To: Swami Yogesh (NRC/Dallas)
> Cc: [email-masked]
> Subject: [Tsvwg] Re: Eifel Detection: Open Issues so far ...
> 
> 

This scenario is not relevant for Eifel detection algorithm, but its very relevant for Eifel response algorithm. The reason it's important is, lets say, we have multiple competing TCP connections, out of which one gets stalled indefinitely. While this connection was stalled, it was not using its share of buffer space in the bottle neck router. The non-stalled connections which share the same bottle neck will see this as resource availability and increase their congestion window by virtue of additive increase ... 

Therefore if we restore the congestion window of the stalled connection, we will lose all the packets that were added by the competing connections during this time period. For example, in the figure below, all connections that share the same bottle_neck_router will utilize the buffer space of stalled connection. If the competing connections increased their congestion window by 10 packets in all, after restoring the window, we will lose these 10 extra packets and possibly force as many as 10 connection to half their data rate and reduce their throughput.

	sender -->bottle_neck_router -->stalling_router--> receiver

Of course, how much buffer will get used up depends upon how long the stalling lasts, how long is the RTT of each connection, and how many connections share that bottle neck. 

If the response algorithm is not prudent enough to take these factors into consideration, it can result in an overall throughput degradation of the system (a stalled connection should not reduce the throughput of non-stalled connection in any way. I guess that's a tacit pre-condition for all these algorithms.) 

Of course, if you have just one TCP connection, or if you have a CBR traffic with one TCP connection (as was pointed out to me), this behavior will not show up.

> Again, I don't quite follow. Please, elaborate a bit more on this.

The congestion window becomes invalid because of the arguments I gave before. The point I was trying to make is that if there is just a single TCP connection in the entire system and if that connection times out--for what ever strange reason--then there is no need to go to slow start. Simply restoring the window will work just fine. To fully appreciate why restoring the window is bad requires test conditions with more than one TCP connection and a bottle neck router that is different from the stalling router.

> to packet loss in the data path. No RFC mandates that it 

If we go by your logic, it will be alright to inject the entire 100M file at start of the connection (since there are no losses at the start of the connection) and then rely on the lost packets to do congestion control. I hope we agree that this is not the right thing to do. 

Packet loss is just one way to determine if there is any congestion in the network. Its not the only way. Besides no RFC makes any recommendation about what events to use to determine congestion. 

If the connection was stalled for more than an RTO, and if one knows that reverting the window size will cause packet loss, then one should take the corrective measure right away, there is no need to rely on loss or any other round about methods. Of course the corrective measure requires more logic than what is present in these drafts. Please also see my e-mail to Sally Floyd for what I mean by "more logic." 

Please also see RFC 2861 and the logic behind it.

> should also be 

I agree.

Thanks
Best Regards
Yogesh