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

Sally Floyd <sallyfloyd@mac.com> Wed, 09 January 2008 00:50 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 1JCP9E-0002Zl-Qc; Tue, 08 Jan 2008 19:50:24 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1JCP9E-0002Zg-7M for tcpm-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 19:50:24 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCP9D-0002YZ-PL for tcpm@ietf.org; Tue, 08 Jan 2008 19:50:23 -0500
Received: from smtpoutm.mac.com ([17.148.16.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCP9C-0003LV-OD for tcpm@ietf.org; Tue, 08 Jan 2008 19:50:23 -0500
Received: from mac.com (asmtp004-s [10.150.69.67]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m090oBvs000831; Tue, 8 Jan 2008 16:50:16 -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 m090o8tl005023; Tue, 8 Jan 2008 16:50:08 -0800 (PST)
In-Reply-To: <200801090007.m09079NU032330@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> <1bb51f3f2858e4828998faf9afb6a745@mac.com> <200801090007.m09079NU032330@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: <e99a136e5319a70a6d91db90de6a9cd6@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: Tue, 8 Jan 2008 16:50:07 -0800
To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
X-Mailer: Apple Mail (2.624)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba
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 -

> I'll accept all your responses...
>
> Except, I probably didn't explain well why I didn't like:
> "This would not be a problem in an environment with mostly long-lived  
> TCP connections..."
>
> This is ambiguous as to whether it means the competing flows are long  
> lived or the ECN+ server's flows are long lived. The problem is short  
> flows from the ECN+server. The problem hits both short and long  
> competing flows.

Great, I will add a clarification.

Mark, is it time for me to submit the revised internet-draft?

- Sally


> At 05:21 08/01/2008, Sally Floyd wrote:
>> 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/
>
> _______________________________________________________________________ 
> _____
> Bob Briscoe, <bob.briscoe@bt.com>      Networks Research Centre, BT  
> Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473  
> 645196
>
- Sally
http://www.icir.org/floyd/



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