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

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:
    In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node
    B must have received an ECN-setup SYN packet from node A.  However,
    it is possible that node A supports ECN, but either ignores the CE
    codepoint on received SYN/ACK packets, or ignores SYN/ACK packets
    with the ECT or CE codepoint set.  If the TCP initiator ignores the
    CE codepoint on received SYN/ACK packets, this would mean that the
    TCP responder would not respond to this congestion indication.
    However, this seems to us an acceptable cost to pay in the
    incremental deployment of ECN-Capability for TCP's SYN/ACK packets.
    It would mean that the responder would not reduce the initial
    congestion window from two, three, or four segments down to one
    segment, as it should.  However, the TCP end nodes would still
    respond correctly to any subsequent CE indications on data packets
    later on in the connection.

    Figure 3 shows an interchange with the SYN/ACK packet ECN-marked, but
    with the ECN mark ignored by the TCP originator.

         ---------------------------------------------------------------
            TCP Node A             Router                  TCP Node B
            ----------             ------                  ----------

            ECN-setup SYN packet --->
                                            ECN-setup SYN packet --->

                                          <--- ECN-setup SYN/ACK, ECT
                               <--- Sets CE on SYN/ACK
            <--- ECN-setup SYN/ACK, CE

            Data/ACK, No ECN-Echo --->
                                                       Data/ACK --->
                                 <--- Data (up to four packets), CWR
         ---------------------------------------------------------------

            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 in a scenario with
    mostly long-lived TCP connections, but it would be more problematic
    in a scenario where all TCP connections consisted of four data
    packets, and the TCP responder was ready to send its data packets
    immediately after the SYN/ACK exchange.  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.

    It is also possible that in some older TCP implementation, the
    initiator would ignore arriving SYN/ACK packets that had the ECT or
    CE codepoint set.  This would result in a delay in connection set-up
    for that TCP connection, with the initiator re-sending the SYN packet
    after a retransmit timeout.  We are not aware of any TCP
    implementations with this behavior.

    One possibility for coping with problems of backwards compatibility
    would be for TCP initiators to use a TCP flag that means "I
    understand ECN-Capable SYN/ACK packets".  If this document were to
    standardize the use of such an "ECN-SYN" flag, then the TCP responder
    would only send a SYN/ACK packet as ECN-capable if the incoming SYN
    packet had the "ECN-SYN" flag set.  An ECN-SYN flag would prevent the
    backwards compatibility problems described in the paragraphs above.

    One drawback to the use of an ECN-SYN flag is that it would use one
    of the four remaining reserved bits in the TCP header, for a
    transient backwards compatibility problem.  This drawback is limited
    by the fact that the "ECN-SYN" flag would be defined only for use
    with ECN-setup SYN packets;  that bit in the TCP header could be
    defined to have other uses for other kinds of TCP packets.

    Factors in deciding not to use an ECN-SYN flag include the following:

    (1) The limited installed base: At the time that this document was
    written, the TCP implementations in Microsoft Vista and Mac OS X
    included ECN, but ECN was not enabled by default [SBT07].  Thus,
    there was not a large deployed base of ECN-Capable TCP
    implementations.  This limits the scope of any backwards
    compatibility problems.

    (2) Limits to the scope of the problem: The backwards compatibility
    problem would not be serious enough to cause congestion collapse;
    with severe congestion, the buffer at the congested router will
    overflow, and the congested router will drop rather than ECN-mark
    arriving SYN packets.  Some active queue management mechanisms might
    switch from packet-marking to packet-dropping in times of high
    congestion before buffer overflow, as recommended in Section 19.1 of
    RFC 3168.  This helps to prevent congestion collapse problems with
    the use of ECN.

    (3) Detection of and response to backwards-compatibility problems: A
    TCP responder such as a web server can't differentiate between a
    SYN/ACK packet that is not ECN-marked in the network, and a SYN/ACK
    packet that is ECN-marked, but where the ECN mark is ignored by the
    TCP initiator.  However, a TCP responder *can* detect if a SYN/ACK
    packet is sent as ECN-capable and not reported as ECN-marked, but
    data packets are dropped or marked from the initial window of data.
    We will call this scenario "initial-window-congestion".  If a web
    server frequently experienced initial-window congestion (without
    SYN/ACK congestion), then the web server *might* be experiencing
    backwards compatibility problems with ECN-Capable SYN/ACK packets,
    and could respond by not sending SYN/ACK packets as ECN-Capable.

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