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

[Sally Floyd <[e-mail]>]

>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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg