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

[Bob Briscoe <[e-mail]>]

Sally,

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.


Bob


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.    [phone] 




_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm