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

[Bob Briscoe <[e-mail]>]

Sally,

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.

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'.

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 /

>    mostly long-lived TCP connections, but it would be more problematic

s/in a scenario where all /with an ECN+ TCP responder where most /

>TCP connections consisted of

at most

>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.

>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.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Cheers


Bob


____________________________________________________________________________
Notice: This contribution is the personal view of the author and does 
not necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           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