Subject: Fwd: Re: [Tsvwg] WG last call on draft-ietf-tsvwg-tcp-eifel-alg-04.txt

From: Reiner Ludwig <[email-masked]>
Date: Thu, 15 Aug 2002 14:09:08 +0200

Something is odd about this mailing list's filter ...

///Reiner

>Date: Tue, 13 Aug 2002 14:05:07 +0200
>To: Pasi Sarolahti <[email-masked]>
>From: Reiner Ludwig <[email-masked]>
>Subject: Re: [Tsvwg] WG last call on draft-ietf-tsvwg-tcp-eifel-alg-04.txt
>Cc: [email-masked]
>
>Hi Pasi,
>
>At 17:25 09.08.2002, Pasi Sarolahti wrote:
>>I have a couple of small comments/questions.
>>
>>First, variable "SpuriousRecovery" in the algorithm description is
>>undefined and unreferenced anywhere in the text. I assume it is left
>>there for the purposes of future recovery algorithms, but wouldn't it
>>be worth of small description? <nit>Btw, is "SpuriousRecovery" boolean,
>>enum, or integer?</nit>
>
>I think it's common practice in IETF documents to specify algorithms using 
>pseudo code. My understanding is that variable definitions are then left 
>to the implementors.
>
>
>>Second, Eifel detection cannot see the possible loss of the (spurious)
>>retransmission. Maybe this is a minor concern, since the retransmission
>>was spurious anyway, but nevertheless, it is a loss caused by network
>>congestion, so in principle the congestion window should have been
>>reduced in that case.
>
>We see your point: All original packets arrive at the receiver, i.e., no 
>congestion losses, but the sender still spuriously retransmits the oldest 
>packet, and that retransmit gets lost.
>
>Yes, the Eifel algorithm ignores that case, but we think that's OK. First, 
>this seems like a pretty pathological case. But even so, one could argue 
>that a TCP sender (e.g., one with a more conservative retransmission 
>timer) that would not have spuriously retransmitted would not have 
>triggered loss recovery / congestion control either.
>
>The Eifel algorithm basically asks the following question: Was the oldest 
>outstanding segment really lost?
>If yes, it does nothing.
>If no, it declares that the loss recovery phase was unnecessarily entered.
>
>The case you brought is a second order problem that is outside of the IDs 
>scope. But, if you believe it helps, we can add a note in the next 
>revision of the ID.
>
>
>>Finally, I am still not 100% convinced that RTO due to loss of ACKs
>>should be interpreted as spurious timeout.
>
>I think you can view it one way or the other. We have chosen to consider 
>this as a spurious timeout. True, when no packet was lost in the data path 
>but all ACKs are lost then the timeout is unavoidable. But, the resulting 
>retransmit will be spurious since the original transmit did arrive, and 
>really there was no congestion in the data path. That's why the Eifel 
>algorithm again declares that the loss recovery phase was unnecessarily 
>entered.
>
>
>>If there are data packets
>>lost in the same window when Eifel is applied due to lost ACKs, the
>>resulting recovery can be quite ineffective, as we have experienced.
>
>Probably true. But if no data packets are lost from the same window for 
>which at that point in time we have no indication than no recovery is 
>needed, anyway.
>
>In more general terms, I believe that you can always find situations where 
>an algorithm does not perform optimal. The question is then whether such 
>situations are common or only rare corner cases.
>
>
>>By
>>inspecting the next couple of acks following the RTO this problem could
>>be avoided
>
>I believe you're right, but that's not the philosophy of the Eifel 
>detection algorithm. The Eifel detection algorithm makes its decision on 
>the *first* acceptable ACK that arrives after loss recovery was entered. 
>And, I believe that we have shown that this decision is reliable. That is, 
>if the algorithm declares that a loss recovery phase was unnecessarily 
>triggered then this in fact true.
>
>I'm sure that one could devise schemes that wait for more than just the 
>first acceptable ACK to hopefully derive further information about what 
>happened in the network.
>
>///Reiner & Michael

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

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 15 Aug 2002 10:59:44 +0200

this e-mail never arrived at the list, so I'm resending it.

///Reiner

---

From: [email-masked]
Date: Fri, 30 Aug 2002 05:31:25 -0500

Hi all,

please see my comments below:

> -----Original Message-----
> From: ext Sally Floyd [mailto:[email-masked]]
> Sent: Tuesday, August 27, 2002 7:03 PM
> To: Scott Bradner
> Cc: [email-masked]; [email-masked]
> It would not seem a big danger to end-to-end congestion control if
> the overall Eifel algorithm occasionally failed to halve its
> congestion window in the rare case when all of the ACKs in a window
> of data were lost.  On the other hand, if the overall Eifel algorithm
> caused the TCP sender to repeatedly fail to halve its congestion
> window in an environment with heavy losses on the return path, when
> all of the ACKs in window of data were frequently lost, then that
> would seem like a problem to me.  I don't have any idea if such a
> scenario is realistic or even theoretically possible.  However, it
> does illustrate one danger of trying to evaluate a detection algorithm
> without considering at the same time the corresponding mechanism
> for using the detection algorithm.
>

The danger of not specifying the mechanism in case of spurious timeout is far more than it seems. Unlike the case of real timeout which is caused by congestion, a spurious timeout is often caused by different set of events that require different response from the sender. Often the mechanism used to detect spurious timeouts will wholly or partly indicate its cause and help to determine the most effective response.

For example, a spurious timeout might be caused due to a mobile terminal moving from one subnet to another. In these cases the entire end-to-end path between the sender and the receiver can completely change. (Please see the figure at the end of this e-mail.) Lets say, a mobile node moves from one access router to another using Mobile-IPv6. The access router on Route-1 can possibly forward the stalled packet to access router on Route 2. However, the acks generated by these stalled packets will trigger data packets on the new path (Route-2). But the sender has no information about the congestion state of the network on the new path, so restoring the congestion window (or even halving it) is an inappropriate behavior. (Please note that such subnet change can happen almost as frequently as once every 5 minutes per mobile. If the number of mobiles is large, it will severely add to the network congestion and effect the throughput of non-mobile terminals sharing one or more those !
routers on the path.)

On the other hand, however, if the spurious timeout was caused due to a once-in-a-while huge RTT fluctuation, then probably halving the congestion window is sufficient (restoring is still a bad idea).

The bottom line is one cannot have just a single response to all kinds of spurious timeouts (just like one does not have a single response to all kinds of congestion; fast retransmit and fast recovery have different detection and response mechanism from slow start--even though they both indicate congestion). Often the mechanism used to detect such timeouts will wholly or partly indicate its cause and help to determine the most effective response.

				path of acks and
			data 	after spurious timeout	 
				   <........>	 
				  +------------>  Mobile (after subnet change)
+-----------------+	  | Route-2	^
| 			+-------+		|
| TCP Sender	|			|(Path of stalled data)
|			+-------+		|
+-----------------+	  | Route-1 |
				  +-------------> Mobile (before subnet change)
						(stalled packets)

My thoughts, if it matters.

Thanks
Best regards
Yogesh