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

From: Reiner Ludwig <[email-masked]>
Date: Wed, 04 Sep 2002 22:14:05 +0200

Hi Sally,

At 02:20 31.08.2002, Sally Floyd wrote:
>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,

I agree, there is no danger of go-back-N in this case.

>and no compelling argument for undoing
>the halving of the congestion window, in my opinion.

Hmmm, I don't know. If, we find that none of the original transmits was 
lost then there hasn't been any congestion in the data path. So, why 
shouldn't the TCP sender be allowed to revert to previous congestion 
control state.

If we left CWND halved then this would be some implicit form of congestion 
control for the ACK path, right?

The scheme you propose to detect the case of all the ACKs being lost works 
if none of the original transmits was lost. However, if in addition some 
but not the oldest outstanding data segment were lost, I still think that 
we would need the SACK and/or the DSACK option ...

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

Eifel detection always remembers the timestamp of the retansmit sent in the 
beginning of loss recovery. It then looks at the timestamp of the first 
acceptable ACK that arrives after loss recovery was entered. If that ACK's 
timestamp is smaller than the timestamp of the retransmit, Eifel detection 
decides that loss recovery was entered unnecessarily.

However, if all ACKs were lost while some but not the oldest outstanding 
data segment were also lost, then the timestamp of the ACK sent in response 
to the retransmit (which arrives as a duplicate, i.e., an out-of-order 
segment) will always be smaller than the timestamp of the retransmit. From 
RFC1323:
           "An ACK for an out-of-order
            segment should therefore contain the timestamp from the most
            recent segment that advanced the window."

So, after a timeout, a cumulative ACK acking below RecoveryPoint (the 
highest sequence number sent when loss recovery was entered) with a 
timestamp smaller than the timestamp of the retransmit could either mean

A.
Some but not the oldest outstanding data segment and all ACKs were lost,
or
B.
No data segments were lost, but one or more consecutive ACKs corresponding 
to the beginning of the original flight was lost

This assumes that the SACK/DSACK option is not used since we still aim at 
not having to mandate the use of SACK and/or DSACK for Eifel. If the SACK 
option was used than distinguishing case A from case B should be easy: the 
first acceptable ACK in case A would carry a SACK option while in case B it 
wouldn't.

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

Severe congestion on the reverse path, and frequently loosing a window 
worth of ACKs (*and* not loosing the oldest outstanding segment) are 
different things, in my opinion.

///Reiner

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