[tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility

[Sally Floyd <[e-mail]>]

To Bob and the working group:

The discussion with Bob Briscoe concerns the following paragraph in
the ECN/SYN draft:

The discussion with Bob Briscoe concerns the following paragraph in
Section 4 of the ECN/SYN draft:

    Backwards compatibility:
    In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node
    B must have received an ECN-setup SYN packet from node A.  However,
    it is possible that node A supports ECN, but either ignores the CE
    codepoint on received SYN/ACK packets, or ignores SYN/ACK packets
    with the ECT or CE codepoint set.  If the TCP initiator ignores the
    CE codepoint on received SYN/ACK packets, this would mean that the
    TCP responder would not respond to this congestion indication.
    However, this seems to us an acceptable cost to pay in the
    incremental deployment of ECN-Capability for TCP's SYN/ACK packets.
    It would mean that the responder would not reduce the initial
    congestion window from two, three, or four segments down to one
    segment, as it should.  However, the TCP end nodes would still
    respond correctly to any subsequent CE indications on data packets
    later on in the connection.  Thus, to be explicit, when a TCP
    connection includes an initiator that supports ECN but *does not*
    support ECN-Capability for SYN/ACK packets, in combination with a
    responder that *does* support ECN-Capabililty for SYN/ACK packets, it
    is quite possible that the ECN-Capable SYN/ACK packets will be marked
    rather than dropped in the network, and that the responder will not
    learn about the ECN mark on the SYN/ACK packet.

There are three choices:

(1) Leave it as it is, and accept it that sometimes, as a cost of
incemental deployment, a SYN/ACK packet would be ECN-marked, and the
originator, with an older TCP implementation (ECN-capable, but not
understanding ECN-marked SYN/ACK packets), would ignore the ECN mark
on the SYN/ACK packet.

(I don't know what the Microsoft, Max OS X, and Linux ECN 
implementations
do about ECN-marked SYN/ACK packets, but I would assume that they
ignore the ECN marks on SYN/ACK packets...)

(2) Use one of the four remaining TCP header flags.  On a SYN packet,
the flag would mean ECN-SYN ("I want to use ECN, and I understand
ECN-marked SYN/ACK packets").  On a packet other than a SYN packet,
the TCP flag could be used for something else.  The responder already
has to look at the TCP header flags to learn that the originator
is ECN-capable, so looking at one more flag should not be a problem.

(3) Use a two-byte ECN-SYN TCP option on SYN packets, meaning "I
understand ECN-marked SYN/ACK packets."  There is at most 40 bytes
for TCP options, and other options that might be carried by SYN
packets include Sack Permitted (2 bytes), MSS (4 bytes), Window
Scale (3 bytes), Timestamp (10 bytes).


The downside of (1) is that during congestion, SYN-ACK packets
could be ECN-marked rather than dropped, and the TCP response
might never find out about the ECN-mark on the SYN-ACK packet.
This could happen if the TCP originator uses an old ECN-Capable
TCP implementation that doesn't response to ECN marks on
incoming SYN/ACK packets, and the congested link has ECN enabled.

The downside of (2) and (3) is that the TCP flag or TCP option
would have to be used in perpetuity, long after all ECN-capable
TCP implementations were updated to respond to incoming ECN-marked
SYN/ACK packets.  This would be a drag for (3), but less of a drag
for (2) - the cost of using one of the four remaining header flags
might be an acceptable cost.


So would the working group like us to use a TCP header flag for this,
or not?

This is scheduled for a 5-minute slot at TCMP on Tuesday, so we
can discuss it then.

- Sally
http://www.icir.org/floyd/



_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm