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

From: Scott Bradner <[email-masked]>
Date: Tue, 27 Aug 2002 20:06:45 -0400 (EDT)

during the discussion a while back Reiner was asked to split the
doc into two parts draft-ietf-tsvwg-tcp-eifel-response-00.txt
is the response side 

it seems reasonable to look at both IDs & I'll poke the list to do that

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

---

From: Sally Floyd <[email-masked]>
Date: Tue, 27 Aug 2002 17:02:48 -0700

Chiming in about the case of an RTO due to the loss of ACKs:

Given the absence of any separate form of congestion control on
reverse-path ACK-only traffic, it seems to me that the ideal behavior
would be to interpret the loss of all of the ACKs for a window of
data as an instance of congestion, and as a consequence to reduce
the sending rate.  So it seems to me that the *ideal* behavior would
be to interpret such an event as a valid retransmit timeout.  My
vote would be for the draft to say that: e.g., "while some
would argue that the ideal behavior would be to interpret such an
event as a valid retransmit timeout, the Eifel detection algorithm
interprets it as a spurious timeout."

At the same time, I agree with Reiner's comment below: 

Reiner:
>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.

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.

About terminology on defining a spurious timeout:

Reiner in email equated a "spurious timeout" with "go-back-N loss
recovery".  Pasi responded as follows:

Pasi:
>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...

I would agree with that.  I agree with Reiner that "go-back-N loss
recovery" is not good, but it doesn't seem helpful to me to define
any "go-back-N loss recovery" as a "spurious timeout".  This probably
just requires being somewhat more precise in terminology.  (It
doesn't seem helpful to me to refer to a timeout from the loss of
a window of acks as a "spurious timeout".)

About Reverting to Previous Congestion Control State:

RFC 2883 on defining DSACK includes the following discussion in
"Research Issues" in Section 5.4:

"After the sender determines that an unnecessary (i.e., early)
retransmit timeout has occurred, the sender could adjust parameters
for setting the RTO, to prevent more unnecessary retransmit timeouts.
Coupled with this, when the sender determines, after the fact, that
it has made an unnecessary window reduction, the sender has the
option of "undoing" that reduction in the congestion window."

My own view is that reverting to the old congestion window after
a spurious timeout is acceptable only if it is accompanied by
some mechanism to prevent frequent spurious timeouts.  But, since
draft-ietf-tsvwg-tcp-eifel-alg-04.txt doesn't discuss the response
to the detection of a spurious timeout, this can perhaps be postponed 
to a later discussion.

- Sally

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 29 Aug 2002 10:37:01 +0300

Hi Sally and others,

I agree with most of your mail. But even with the risk of repeating 
myself, I would like to clarify one point.

On Wednesday 28 August 2002 03:02, ext Sally Floyd wrote:

> 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.

We made test runs with random burst loss events of random lenghts. On 
those test cases Eifel throughput was constantly worse than standard 
TCP, regardless of whether SACK was used or not. It does not require 
loss of all ACKs in the window, it is enough that a loss burst triggers 
RTO and the first loss happens to be in the ACK stream. The report at 
http://www.cs.Helsinki.FI/group/iwtcp/papers/f-rto.ps shows the 
performance numbers resulted from our study, if anyone is interested. 
The test model was not exactly taken from any real world network, but I 
believe that for example 802.11 WLAN is more likely to involve burst 
losses on the link rather than delay spikes, right? If that is the 
case, WLAN users would probably want to switch TCP timestamps off in 
order to improve TCP performance.

Avoiding unnecessary retransmits and aggressiveness of unnecessary slow 
start are important goals in networks that have delay spikes. But I'm 
afraid that although Eifel does good work with delay spikes, deciding 
immediately after RTO whether the loss event is spurious is not 
reliable enough in general case. Or at least, loss of ACK should not be 
a signal for spurious RTO. Instead, we are advocating a method in which 
the sender would conditionally continue sending new data after RTO 
retransmission, but it would enter go-back-N, when it detects duplicate 
ACKs after RTO, which is good enough indication of non-spurious RTO in 
that case, since there likely has been data loss in that case. It is 
easy to implement and does not require TCP options.

- Pasi

---

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

Pasi,

At 09:37 29.08.2002, Pasi Sarolahti wrote:
>TCP, regardless of whether SACK was used or not. [...]

You don't seem to get tired of repeating that, and I have replied a couple 
of times: *yes*, the throughput of TCP with Eifel can in certain situations 
be less than what standard TCP gives you. But, this is only because 
standard TCP breaks packet conservation in the situations you refer to.

In many other situations, though, TCP with Eifel outperforms standard TCP 
by far. This is true for throughput but even more so when considering the 
metric "goodput" which can be quite important if you're running on battery.

>reliable enough in general case.

Unless, you present a case where Eifel detection makes the wrong decision 
(assuming our current definition of spurious timeout), you shouldn't make 
such claims.

>Or at least, loss of ACK should not be
>a signal for spurious RTO.

See my mail to Sally.

>Instead, we are advocating a method [...]

I think we should not mix discussing Eifel detection/response with your 
proposal. Maybe, you want to open a separate thread for that.

///Reiner

---

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

Sally,

I have given this thread a separate subject line to make it easier to keep 
track ...

>interprets it as a spurious timeout."

Fine. That sounds reasonable, and I'll include that in the next revision.

I would like to explain why we ended up with the current definition of a 
spurious timeout given in the -04 version of the draft:

I admit that it sounds odd to call a timeout that occured because an entire 
window of ACKs got lost *while (at least) the oldest outstanding segment 
was not lost* a spurious timeout. This is even more so since such a timeout 
is unavoidable. However, also in this situation does the standard TCP 
sender "misbehave" since it does a go-back-N in slow start, potentially 
breaking packet conservation. I.e., it retransmits all outstanding segments 
at double ACK-clock speed without knowing whether those segments were lost 
or not.

It was our intention to have Eifel detection detect this case to give 
response schemes, e.g., Eifel response, the chance to avoid the go-back-N. 
Also, we didn't find it worth to distinguish that case from the common case 
of a spurious timeout where the retransmission timer simply fired to quick 
(usually because of a sudden delay spike on the path). This is because we 
believe that "loss of all ACKs while (at least) the oldest outstanding 
segment was not lost" must be a pretty rare corner case.

If we really wanted to make this a special case that the TCP sender could 
detect as such, I see no other alternative but to use the DSACK option. But 
that would only make things more complicated, and I don't think that effort 
is worth the benefit.

>of data were lost ...

one needs to add: "... while (at least) the oldest outstanding segment was 
not lost".

Only in that case does Eifel detection announce that loss recovery was 
entered unnecessarily, and the Eifel response reacts by avoiding the 
go-back-N, reversing congestion control state, and re-initializing SRTT and 
RTTVAR.

If all ACKs were lost but also the oldest outstanding segment, Eifel 
detection/response does nothing.

>On the other hand, if the overall Eifel algorithm
>scenario is realistic or even theoretically possible.

So, the scenario in which Eifel would repeatedly reverse to the previous 
congestion control state would be: never a loss of the segment for which 
the timeout occured & loss of all ACKs in that case. (Sounds pretty 
pathological to me.)

>However, it

That's why I suggested to Scott Bradner to consider
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-alg-04.txt
and
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-00.txt
together.

>I agree with Reiner that "go-back-N loss

See above. Unless we also mandate the use of DSACK, the TCP sender has no 
way to distinguish between the two cases of what have defined as a spurious 
timeout.

Please, also note that standard TCP inevitably goes into go-back-N loss 
recovery in either case. So, both terms, "go-back-N loss recovery" and 
"spurious timeout", are somewhat tied together.

///Reiner

---

From: Pasi Sarolahti <[email-masked]>
Date: Fri, 30 Aug 2002 11:28:16 +0300

On Thursday 29 August 2002 14:43, ext Reiner Ludwig wrote:

> So, the scenario in which Eifel would repeatedly reverse to the
> previous congestion control state would be: never a loss of the
> segment for which the timeout occured & loss of all ACKs in that
> case. (Sounds pretty pathological to me.)

How about this:
A wireless link with not-very-persistent retransmissions. Packets 5-15 
are unacknowledged, of which packets 5-8 have arrived at the receiver 
having acks coming on the return path. The wireless link momentarily 
loses coverage and the packets on the link are lost. In this case I 
assume most of the outstanding packets were on the wireless link, since 
it usually has considerably longer delays than the fixed portion of the 
network. So the pipe gets out of packets and RTO results at the sender, 
retransmitting segment 5 that had already arrived at the receiver.

Is this case pathological (e.g. on WLAN links or satellite links)? I 
don't have any data on how frequently this happens, but I have noticed 
that WLAN tends to drop packets every once in a while.

And this is just the case where, without NewReno+limited transmit or 
with SACK the Eifel sender suffers from two consecutive RTOs, compared 
to one RTO of standard TCP. If NewReno+limited transmit is in use, the 
sender retransmits the whole window one packet at a time (as forced by 
partial acks). Packet conservation holds, but performance is quite crap 
in my opinion (retransmissions take N*RTT, where N is number of 
outstanding data packets). Although I don't understand what preserving 
packet conservation has to do with this (or the claimed breaking of 
packet conservation), since all packets were lost.

> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-alg-04
>.txt and
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-respon
>se-00.txt together.

I agree on this. Detection draft doesn't specify any change on any 
protocols, it just informs that you can use timestamps to separate ack 
of retransmission from ack of original segment. There is nothing wrong 
with this logic. (Btw, why the detection draft is going to be 
"Experimental" instead of "Informational"?)

The interesting part is how to use this information, and I have tried 
to say that the timestamp information of the first retransmitted 
segment alone is probably not sufficient enough to make correct 
decissions in general case about whether to stay in slow start or 
whether to transmit new segments in congestion avoidance.

Thanks for your patience. I'll try to fade back to read-only mode again 
:-)

- Pasi

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 30 Aug 2002 11:06:32 +0200

At 10:28 30.08.2002, Pasi Sarolahti wrote:
>assume most of the outstanding packets were on the wireless link,

You as a global observer might know that. But, the TCP sender has no clue 
about where packets 5-15 are. The TCP sender usually doesn't even know (and 
doesn't need to know) whether the path includes a wireless link.

Packet conservation means that the TCP sender has to be conservative and 
assume that those 11 packets are still in the network. And that could in 
fact be the case: simply replace the "not-very-persistent" with 
"very-persistent" in your example. Same example, no data segments lost.

>that WLAN tends to drop packets every once in a while.

Having a link that drops a packet every once in a while is unlikely to 
result into the case we're discussing: "the segment for which the timeout 
occured did in fact arrive at the TCP receiver & loss of all ACKs in that 
case".

>Although I don't understand what preserving

There is a (maybe subtle) but very important difference between "the global 
observer knows that certain packets were dropped in the network" and "the 
TCP sender knows that certain packets were dropped in the network".

///Reiner