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

Bob Briscoe <rbriscoe@jungle.bt.co.uk> Fri, 04 January 2008 18:04 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAquO-0001Du-S4; Fri, 04 Jan 2008 13:04:40 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JAquN-0001DF-L0 for tcpm-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 13:04:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAquN-0001CK-16 for tcpm@ietf.org; Fri, 04 Jan 2008 13:04:39 -0500
Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAquK-0000Ww-M7 for tcpm@ietf.org; Fri, 04 Jan 2008 13:04:39 -0500
Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 18:04:35 +0000
Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 18:04:35 +0000
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1199469874302; Fri, 4 Jan 2008 18:04:34 +0000
Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m04I4O2L008832; Fri, 4 Jan 2008 18:04:32 GMT
Message-Id: <200801041804.m04I4O2L008832@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 04 Jan 2008 18:04:15 +0000
To: mallman@icir.org
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility
In-Reply-To: <20080104140011.B80A7328DFE@lawyers.icir.org>
References: <9ee77c9bed4cf392d49f6aeff4774470@mac.com> <20080104140011.B80A7328DFE@lawyers.icir.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: -1.36 () ALL_TRUSTED
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 04 Jan 2008 18:04:35.0277 (UTC) FILETIME=[43973FD0:01C84EFC]
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc: Aleksandar Kuzmanovic <akuzma@northwestern.edu>, "K. K. Ramakrishnan" <kkrama@research.att.com>, Amit Mondal <a-mondal@northwestern.edu>, tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

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
> > tcpm@ietf.org
> > 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.    +44 1473 645196 




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm