Subject: [Tsvwg] Eifel Detection & Loss of all ACKs

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

Sally,

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

At 02:02 28.08.2002, Sally Floyd wrote:
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."

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.

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

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

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

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

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

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

---

From: Sally Floyd <[email-masked]>
Date: Fri, 30 Aug 2002 17:20:36 -0700

>But, if we wanted to treat that case separately, we can't rely solely on 
>timestamps. Please, see section 3.3 of the current draft. We could only 
>make it work for non-RFC1323-compliant TCP receivers that follow the 
>RFC1323 update attempt by Bob Braden: 
>http://www.kohala.com/start/tcplw-extensions.txt. But that doesn't seem 
>like a good way to go ...

Well, it seems to me that it would be easy to treat this case (of 
all the ACKs being lost) as follows:

After an RTO, and the retransmission of the presumed lost packet
P, and the receipt of an ACK, notice if the ACK acknowledges all
of the packets transmitted before the RTO.  If so, then whether or
not the presumed lost packet P was or was not in fact lost, there
is no danger of Go-back-N, and no compelling argument for undoing
the halving of the congestion window, in my opinion.  (Of
course, if you had DSACK, then you could tell for sure if none of
the data packets had been lost in the forward path, but since you
would have to halve the congestion window in any case, in my opinion
(whether a data packet was lost, or all of the ACK packets were
lost), then I don't see that it makes a big difference one way or
another.

The danger of Go-back-N only occurs if, after retransmitting the
packet, an ACK is received for the retransmitted data, but not
acknowledging all of the packets transmitted before the RTO.  And
the Eifel algorithm, or some other mechanism for preventing Go-back-N,
can tell if this is the case as soon as it receives that ACK (i.e.,
the first ACK for the data in the retransmitted packet).

>Also, I still believe that we're discussing an extremely exotic scenario: 
>"the segment for which the timeout occured did in fact arrive at the TCP 
>receiver & loss of all ACKs in that case" + that event needs to occur 
>sufficiently frequent over the lifetime of a TCP connection for this to 
>become a real problem.
>
>I would argue that any TCP that has to run across a network exhibiting such 
>characteristics and the network itself has some serious problems; with or 
>without Eifel.
>
>So, at this point I believe that we're discussing a non-(real-world-)issue.

My own opinion would be that the issue of severe congestion on
reverse paths is a real-world issue that can not be ignored.  The
good news is that it would not be hard, I believe, to modify the
Eifel detection/response mechanisms to respond appropriately in
this case (of all of the ACKs being lost), just by remembering the
highest sequence number sent before the RTO, and looking at the
cumulative acknowledgement field in the first ACK received for the
data transmitted after the RTO.  (This supports the argument for a
coupling between the detection and the response mechanisms, it seems
to me.)

The ideal, in my opinion, would be some form of congestion control
on the pure ACK stream on the reverse path, but we haven't gotten
there yet.  But for documentation of other people who are concerned
about congestion on the reverse path, possibly because of asymmetric
paths, you would look at draft-ietf-pilc-asym-07.txt on "TCP
Performance Implications of Network Path Asymmetry".

- Sally
http://www.icir.org/floyd/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg