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

Sally Floyd <> Tue, 08 January 2008 05:21 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1JC6uQ-0000qG-Bu; Tue, 08 Jan 2008 00:21:54 -0500
Received: from tcpm by with local (Exim 4.43) id 1JC6uO-0000qB-Lk for; Tue, 08 Jan 2008 00:21:52 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1JC6uO-0000oR-8z for; Tue, 08 Jan 2008 00:21:52 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1JC6uN-0008BV-4K for; Tue, 08 Jan 2008 00:21:52 -0500
Received: from (asmtp004-s []) by (Xserve/smtpout004/MantshX 4.0) with ESMTP id m085LiKu020956; Mon, 7 Jan 2008 21:21:44 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (Xserve/asmtp004/MantshX 4.0) with ESMTP id m085Lf9l020696; Mon, 7 Jan 2008 21:21:41 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: Sally Floyd <>
Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility
Date: Mon, 7 Jan 2008 21:21:40 -0800
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.624)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92
Cc:, Aleksandar Kuzmanovic <>, "K. K. Ramakrishnan" <>, Amit Mondal <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Bob -

> The new text outlines the issues well (I've suggested some minor  
> changes inline - all in the para below Fig 2).
> But I'm not a great fan of writing long complicated text in standards  
> track documents that describes a problem, when it's sort of hinting  
> that implementers don't actually need to do anything about it. One way  
> round this would be to move this text about incremental deployment to  
> an appendix.

Yep, I will do that.
> Point (3) is a good one that I hadn't thought of.
> Here's strawman text for a solution that could be put in the body.  
> I've used the terms 'TCP clients' and 'TCP servers' for machines used  
> mostly as initiators or responders respectively:
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ 
> \/\
> "There is a potential incremental deployment problem in circumstances  
> we believe will be unlikely, described in (Appendix X). In monitoring  
> the deployment of ECN and ECN+, if significant numbers of queues have  
> ECN turned on and if we find that large numbers of TCP clients still  
> have legacy ECN enabled while significant numbers of TCP servers have  
> upgraded to ECN+, the management application described below could be  
> deployed on ECN+ servers, particularly if most of the flows served fit  
> within an initial window.
> The management application could monitor the average fraction of ACKs  
> with ECE set in response to:
>         1. a SYN/ACK
>         2. the segments in the initial window.
> If the former fraction was significantly lower than the latter, the  
> management application could switch ECN+ back to ECN, perhaps  
> requiring manual intervention rather than automatic switching.
> Once the community deemed that the deployment situation had become  
> safer for ECN+, server administrators could switch ECN+ back on,  
> either leaving the managment application running, or eventually  
> removing the management application.
> Therefore, all ECN+ TCP implementations SHOULD provide the following  
> management interfaces, in order to ease installation of such a  
> management application after the TCP has been upgraded to ECN+:
>         o An interface to turn ECN+ on or off;
>         o An interface to read a count of only those ACKs with ECE set  
> that were responses to SYN/ACKs."
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ 
> \/\
> I said this is strawman text, because I'm not sure I even support it  
> myself. I'm just trying to work through the minimum implementers would  
> need to do about incremental deployment other than 'nothing'.

I am inclined to leave that out, for now.
Unless others have other opinions.

But I did add a moderated version as follows:

"The TCP implementation using ECN-Capable SYN/ACK packets SHOULD
include a management interface to allow the use of ECN to be turned
off for SYN/ACK packets.  This is to deal with possible backwards
compatibility problems such as those discussed in Appendix B."

> The alternative of doing absolutely nothing about incremental  
> deployment right now is still possible. The above required management  
> interfaces can be added by upgrading the kernel any time. I just  
> figured the above might be worthwhile to ease installation of a little  
> monitoring application, so at least sysadmins can simply test whether  
> there is a problem if they choose to.
> [BTW, there are cases where the approach in (3) wouldn't work (e.g. if  
> SYN/ACKs had a significantly lower probability of ECN marking than  
> data packets). But I really don't think we should start down that  
> rat-hole in this I-D - it would be like describing a pimple on a spot  
> on a flea.]
> A little more inline...
> At 19:50 04/01/2008, Sally Floyd wrote:
>> Bob -
>> ...
>>> 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.
>> I think it is safe not to use a flag for ECN-Capable SYN/ACK packets,
>> but I wouldn't have any problems with using a flag either.
>> The revised text for draft-ietf-tcpm-ecnsyn is attached below.
>> - Sally
>>    Backwards compatibility:
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ 
> \/
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ 
> \/\
>>            Figure 2: SYN exchange with the SYN/ACK packet marked,
>>              but with the ECN mark ignored by the TCP initiator.
>>    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 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.  This would not be a problem
> s/ in a scenario with/ with machines serving /

I changed "scenario" to "environment"

>>    mostly long-lived TCP connections, but it would be more problematic
> s/in a scenario where all /with an ECN+ TCP responder where most /

I changed "scenario" to "environment" here also, and changed
"all" to "much".

>> TCP connections consisted of
> at most

I left it as it.  If all TCP connections used an initial window of
one data packet, or had only one data packet to send, for example,
then ECN+ wouldn't have as large backwards compatibility problems.
(That is, the congestion control situation would be pretty bad with
or without backwards compatibility problems with ECN+.)

>> four data
>>    packets, and the TCP responder was ready to send its data packets
>>    immediately after the SYN/ACK exchange.
> If correctly responding ECN-capable traffic shared a bottleneck with  
> traffic from such an ECN+ machine, its rate would be continually  
> beaten down by the ECN+ machine's reduced congestion response.


>> Of course, with *severe*
>>    congestion, the SYN/ACK packets would likely be dropped rather than
>>    ECN-marked at the congested router, preventing the TCP responder  
>> from
>>    adding to the congestion by sending its initial window of four data
>>    packets.
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ 
> \/\

- Sally

tcpm mailing list