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

[Mark Allman <[e-mail]>]

Folks-

Bob raised a point about a case where a CE mark can be masked in the
ECN-SYN scheme that is under WGLC.  Sally's summary is appended below.
It seems from the discussion in Vancouver and the silence on the list
that there is not much consensus to change the document's current state
(which is approach (1) below---i.e., do nothing).  If folks have a
different opinion on this question they need to speak up quite fast as
it seems this document is ready to forward.

Thanks!

allman
(tcpm co-chair)




> 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
 

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