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

Sally Floyd <sallyfloyd@mac.com> Tue, 08 January 2008 05:21 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 1JC6uQ-0000qG-Bu; Tue, 08 Jan 2008 00:21:54 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JC6uO-0000qB-Lk for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 00:21:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC6uO-0000oR-8z for tcpm@ietf.org; Tue, 08 Jan 2008 00:21:52 -0500
Received: from smtpoutm.mac.com ([17.148.16.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC6uN-0008BV-4K for tcpm@ietf.org; Tue, 08 Jan 2008 00:21:52 -0500
Received: from mac.com (asmtp004-s [10.150.69.67]) by smtpoutm.mac.com (Xserve/smtpout004/MantshX 4.0) with ESMTP id m085LiKu020956; Mon, 7 Jan 2008 21:21:44 -0800 (PST)
Received: from [192.168.1.101] (adsl-70-132-0-53.dsl.snfc21.sbcglobal.net [70.132.0.53]) (authenticated bits=0) by mac.com (Xserve/asmtp004/MantshX 4.0) with ESMTP id m085Lf9l020696; Mon, 7 Jan 2008 21:21:41 -0800 (PST)
In-Reply-To: <200801060012.m060Bc8e031128@bagheera.jungle.bt.co.uk>
References: <9ee77c9bed4cf392d49f6aeff4774470@mac.com> <20080104140011.B80A7328DFE@lawyers.icir.org> <200801041804.m04I4O2L008832@bagheera.jungle.bt.co.uk> <d5e6611a4ea0c4c0c54718e4b6310bab@mac.com> <200801060012.m060Bc8e031128@bagheera.jungle.bt.co.uk>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1bb51f3f2858e4828998faf9afb6a745@mac.com>
Content-Transfer-Encoding: 7bit
From: Sally Floyd <sallyfloyd@mac.com>
Subject: Re: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility
Date: Mon, 7 Jan 2008 21:21:40 -0800
To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
X-Mailer: Apple Mail (2.624)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92
Cc: tcpm@ietf.org, Aleksandar Kuzmanovic <akuzma@northwestern.edu>, "K. K. Ramakrishnan" <kkrama@research.att.com>, Amit Mondal <a-mondal@northwestern.edu>, mallman@icir.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

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
>> http://www.icir.org/floyd/
>>
>>
>>    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.

Yep.

>> 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
http://www.icir.org/floyd/



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