Subject: [Tsvwg] Fwd: I-D ACTION:draft-ludwig-tsvwg-tcp-eifel-alg-00.txt

From: Reiner Ludwig <[email-masked]>
Date: Thu, 23 Nov 2000 11:39:46 +0100

I would very much appreciate to get some feedback on this mailing list 
concening draft-ludwig-tsvwg-tcp-eifel-alg-00.txt.

///Reiner

>To: IETF-Announce: ;
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-ludwig-tsvwg-tcp-eifel-alg-00.txt
>Date: Tue, 21 Nov 2000 05:56:28 -0500
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : The Eifel Algorithm for TCP
>         Author(s)       : R. Ludwig
>         Filename        : draft-ludwig-tsvwg-tcp-eifel-alg-00.txt
>         Pages           : 12
>         Date            : 20-Nov-00
>
>TCP's intertwined error and congestion control is not robust against
>spurious timeouts nor is it robust against packet re-orderings. A
>packet that is delayed in the network beyond the expiration of TCP's
>retransmission timer, is mistaken for a packet loss by a TCP sender.
>Also, a packet that is re-ordered in the network beyond TCP's
>duplicate acknowledgment threshold, is eventually mistaken for a
>packet loss by a TCP sender. Both situations lead to a spurious
>retransmit of the oldest outstanding segment, and an unnecessary
>reduction of the congestion window at the sender. Moreover, a
>spurious timeout forces the sender into a go-back-N retransmission
>mode leading to spurious retransmits of all outstanding segments.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ludwig-tsvwg-tcp-eifel-alg-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ludwig-tsvwg-tcp-eifel-alg-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ludwig-tsvwg-tcp-eifel-alg-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ludwig-tsvwg-tcp-eifel-alg-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ludwig-tsvwg-tcp-eifel-alg-00.txt>

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

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 23 Nov 2000 15:36:14 +0000 (GMT)

> concening draft-ludwig-tsvwg-tcp-eifel-alg-00.txt.

wouldn't D-SACK information make Eifel flag negotiation redundant,
while also allowing simplifying timestamp handling somewhat?

The Eifel algorithm using D-SACK would be an interesting addition to
the approaches your draft outlines; if Eifel flag negotiation fails
but D-SACK info is present, I'd imagine that Eifel could still be made
to work effectively, even without the use of timestamps.

(Given a choice between SACK/D-SACK and echoing timestamps in headers
for small(ish) header sizes, I'd take the SACK, thanks. It just lets
you do more and be more creative at the sender. See RFC2883.)

I think the most valuable part of the flag approach is:

   The receiver SHOULD send an immediate ACK with the Xmit-Echo flag set
   in response to an incoming data segment that has the Xmit flag set.

since then the sender has the chance to demand real path delay without
the arbitrary delayed acknowledgement timer getting in the way at the
receiver, and to compensate for long path delays for e.g. telnet by
setting the flag a lot.

L.

thinks ack delay should increase the longer ack delay is used as
in-order packets come in. (you'd need byte counting, of course.)

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 23 Nov 2000 16:25:24 +0000 (GMT)

> while also allowing simplifying timestamp handling somewhat?

okay, now I reread section 2 of your draft where D_SACK is dismissed -
but I'm having trouble following the logic for its dismissal. With
SACK information about the receiver window, why does an extra segment
retransmission matter? (This is separate to deciding to restore
previous window sizes based on received ino in acks, be it Eifel bits
or D-SACK.)

L.

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 23 Nov 2000 22:49:16 +0100

>while also allowing simplifying timestamp handling somewhat?

Unfortunately, D-SACK does not help you to reliably detect a spurious 
timeout as soon as it is required to avoid the go-back-N. Consider,
a) a timeout in response to a genuine packet loss, and
b) a spurious timeout.

The first ACK that arrives back at the sender acking the retransmit will 
"look the same" in both cases; with or without D-SACK. Thus, the sender 
would have no way to tell whether that ACK was triggered by the original 
transmit or the retransmit, i.e., the sender would not know (at that point) 
whether the last timeout was spurious or not.

>receiver, and to compensate for long path delays for e.g. telnet by

You should also read the "security consideration" section. That forbids 
such abuse of the Xmit flag. The Xmit flag MUST only be set for 
retransmits. It MUST NOT be set in any other case.

///Reiner