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

[Bob Briscoe <[e-mail]>]

Mark,

'Do nothing' would be a relatively safe option if we assume most 
legacy ECN in TCPs used as clients will be updated to ECN+ before:
a) they interact with those legacy implementations of ECN already out 
there on servers and
b) before ECN is widely deployed on routers.

The largest implementation-base of legacy ECN is currently in Windows 
Vista which has ECN turned off by default. I assume the population of 
other implementations in TCPs used as clients is small.

I've noted a general lack of concern/interest here about 
standardising a congestion control that doesn't respond to congestion 
in a set of circumstances that might happen or might not. I assume 
this is because of the glacial deployment of ECN so far.

If the world turns out differently to the above assumptions, we will 
have to think of a plan B pretty snappish.

But I'm not going to hold this up further, as ECN+ is generally a 
good idea, and the other alternatives for incremental deployment are 
cumbersome.


Bob


At 14:00 04/01/2008, Mark Allman wrote:

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

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does 
not necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone] 




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