Subject: [Tsvwg] Eifel vs. DCLOR

From: [email-masked]
Date: Thu, 21 Nov 2002 13:26:02 -0600

Hi,

Since now we have 4 different schemes for spurious timeout detection and response, I thought it will be useful to have a comparison of all these schemes. This should help us understand the tradeoffs involved. Here is a comparison of Eifel (I use the term Eifel to mean both detection and response algorithm) with DCLOR.

1) Eifel sends new data for the stale ACKs (ACKs generated in response to the stalled packets). DCLOR does not send anything for stale ACKs. This may sound inefficient, but since a spurious timeout may be caused due to sender or receiver mobility (and in most cases the TCP sender will not know about mobility), not sending new data for stale ACKs is the right thing to do.

I personally believe that the bulk of spurious timeouts are caused mainly due to user's mobility. Subnet change should therefore be an important consideration in the design of response algorithm. I cannot emphasize this more.

Another thing to note is that DLCOR sends new data, so the impact of no new data is offset by the new data  sent during the back-off period.

2) For each RTO, Eifel sends the same first segment over and over again. DCLOR on the other hand sends new data whenever possible. This improves the throughput for DCLOR because the TCP sender is still able to send useful data during the timeout period. The downside is that in case of packet loss due to congestion, the data delivery to upper layers will be delayed by one RTT.

For non-interactive applications like FTP and vanilla HTTP, throughput is more important. For interactive traffic, data delivery to upper layers is probably more important. So I am not sure which one of the two is better.

3) DCLOR recovers losses using slow start which is much faster than loss recovery using fast-retransmit/fast-recovery that is used by Eifel. In fact one can analytically show that if the
number of packets lost is more than (flight-size/2 - 2), it's better to use slow-start. Since the number losses in case of Eifel depends upon the number of competing TCP connections  (see DCLOR draft for this) in the network, its not unlikely to have those many losses because of the aggressive response algorithm.

4) Eifel requires time-stamp option, which means each and every packet will have an overhead of at least 10 bytes. With DCLOR, extra bytes for SACK are needed only when there are gaps in the receiver's queue. I don't think this is a big issue. I personally think every TCP sender and receiver should implement each and every TCP option. 

Please give us your comments.

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

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 25 Nov 2002 17:13:52 +0100

Yogesh,

I believe that there is consensus in the TSV working group that there is 
not the one and only detection algorithm nor the one and only response 
algorithm for a spuriously triggered loss recovery phase. I.e., within the 
limits of RFC2581 (TCP Congestion Control) and RFC2914 (Congestion Control 
Principles) there is likely to be enough room for multiple alternatives. 
Thus, if you get consensus for your DCLOR proposal, then fine.

With this in mind I will try to respond to the issues you raised with 
respect to the Eifel Detection and Response algorithms ...

At 20:26 21.11.2002, [email-masked] wrote:
>1) Eifel sends new data for the stale ACKs (ACKs generated in response to 
>the stalled packets).

I call them 'late' ACKs, but otherwise you're right.

>[...] not sending new data for stale ACKs is the right thing to do.

The 'packet conservation' principle allows the sending of another packet in 
return for an ACK. As long as the TCP sender has no reason to believe that 
data was lost, which is the case here, the TCP sender may very well send a 
packet containing new data. So, this is fine.

If you want to be more conservative with DCLOR this is also fine.

>I personally believe that the bulk of spurious timeouts are caused mainly 
>due to user's mobility. [...]

I think, we should not be designing TCP solutions specific to certain 
subnetworks. Instead, any TCP enhancement should be of general value.

>2) For each RTO, Eifel sends the same first segment over and over again.

It is not Eifel that does that. It is RFC2988 that requires every TCP 
sender to do that.

>3) DCLOR recovers losses using slow start which is much faster than loss 
>recovery using fast-retransmit/fast-recovery that is used by Eifel.

True, and I had similar discussions with Pasi, the author of the F-RTO 
draft ...

If many packets from the same flight are lost, a (blind) recovery with slow 
start is most likely to be fastest. This is the current standard TCP 
behavior after a spurious timeout. Note, though that in many cases this 
breaks the 'packet conservation' principle. TCP with Eifel is actually more 
conservative in this case. This may even reduce the incentive to implement 
the Eifel response. To avoid that, we have decided to allow (the TCP sender 
MAY use) a more advanced loss recovery scheme similar to NewReno after a 
spurious timeout. You can read all about it in the next revision of the 
Eifel Response algorithm, and in more detail in a paper that Andrei and I 
have got accepted to INFOCOM 2003.

>4) Eifel requires time-stamp option, which means each and every packet 
>will have an overhead of at least 10 bytes.

12 bytes.

///Reiner

---

From: [email-masked]
Date: Mon, 25 Nov 2002 15:21:35 -0600

Hi Reiner, all,

The purpose of my previous e-mail was just to highlight the trade offs involved with different schemes (I will send another e-mail comparing FRTO and DCLOR). As long as we clearly identify these trade offs with regard to throughput and spectral efficiency, it's okay to consider any of these schemes.

> Principles) there is likely to be enough room for multiple 

I agree to having multiple detection schemes. But if the response algorithm is to be separate from the detection scheme, then there should be just one response algorithm because the response algorithm would not know what caused the timeout. This also means that the response algorithm should be the most conservative of all the possible schemes. 

> packet containing new data. So, this is fine.

In a multiple TCP connection scenario--the mantra I have been singing all along--there are good reasons to believe that multiple packets will be lost if the TCP sender restores its window (this loss is different from the loss of packets from the stalled window). Please see Figure 2 and the related text of DCLOR draft for the reasoning behind it (one can also verify it with simulations if the analytical arguments sound too far-fetched). 

> subnetworks. Instead, any TCP enhancement should be of general value.

I was not suggesting a solution that is specific to a certain subnet. But as I said before, if the detection and response algorithms are separated from each other, then the response algorithm should be the most conservative of all schemes. Change of subnets requires us to have a window of no more than initial window and that's why I was referring to it.

By the way, I am still of the opinion that both detection and response algorithms should be coupled together so that one can fine-tune the response algorithm with the right detection algorithm. This will be very similar to what we have right now for loss detection and loss recovery algorithms (timeout ==> slow start vs. single loss ==> fast-retransmit/fast-recovery).

> the Eifel response. To avoid that, we have decided to allow 

I don't think it's going to reduce the incentive to implement Eifel or any other scheme for that matter. Sending a lot of data does not necessarily means that they will also reach the receiver.

The reason why "blind slow start" works better than Eifel is that the first N packets in slow start are redundant, and even if these redundant packets are lost, it does not matter to that connection. But if we have multiple TCP connections this __does__ show up in the over all throughput of the system taken as a whole. Please see the results in Appendix-1 of DCLOR.

Thanks
Best regards
Yogesh