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

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