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

[Sally Floyd <[e-mail]>]

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, <[e-mail]>      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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm