Subject: Re: [tcpm] ECN for SYN/ACK draft

From: Sally Floyd <[email-masked]>
Date: Tue, 17 Jan 2006 22:14:44 -0800

Pasi -

>To me the proposal seems pretty straightforward and well justified, and
>I'd be happy to see this going forward without delays.
>
>This sentence got me puzzled in the last paragraph of Section 2:
>
>   "If the sending node (node B) was going to use an
>   initial window of one segment, and receives an ECN-Echo packet
>   informing it of a Congestion Experienced indication on its SYN/ACK
>   packet, the sending node MAY continue to send with an initial window
>   of one segment, without waiting for a retransmit timeout."
>
>I don't have opinion for or against this right now, but having TCP
>sender not slow down its sending rate in this particular case got me a
>bit alarmed. On the other hand, I realize this is a pretty minor thing,
>and one motivation of the draft is to avoid retransmit timeouts for
>SYN/ACKs, but maybe the draft could then say that this is not thought to
>be a significant concern for the network? (Especially since RFC 3168
>argues that it is necessary to slow down the sending rate also when
>cwnd=1 and ECN-Echo arrives)

Yep, Mark Allman also raised the same point.

At the moment, I have the following text added to the draft:

   Response to ECN-marking of SYN/ACK packets:
   One question is why TCP SYN/ACK packets should be treated differently
   from other packets in terms of the packet sender's response to an
   ECN-marked packet.  Section 6.1.2 of RFC 3168 specifies that when the
   TCP congestion window consists of a single packet and that packet is
   ECN-marked in the network, then the sender must reduce the sending
   rate below one packet per round-trip time, by waiting for one RTO
   before sending another packet.  If the RTO was set to the average
   round-trip time, this would result in halving the sending rate;
   because the RTO is in fact larger than the average round-trip time,
   the sending rate is reduced to less than half of its previous value.

   It might seem at first glance that the comparable response in reply
   to the ECN-marking of the SYN/ACK packet would be for the packet
   sender to reduce its sending rate by waiting for one RTO before
   sending the next packet.  However, this would not result in halving
   the sending rate; the packet sender has only sent one packet, the
   SYN/ACK packet, so there is no sending rate to halve.  If the RTO is
   set to its default initial value of three seconds, this would also
   not reduce the sending rate to one packet every two round-trip times,
   because the default three seconds could be much larger (or, in
   extreme cases, much smaller) than the actual round-trip time.

   One possibility would be for the packet sender to measure the round-
   trip time T between the sending of the SYN/ACK packet and the receipt
   of the acknowledgement, and to reply to the ECN-marking of the
   SYN/ACK packet by waiting T seconds before sending another packet.
   Conceptually, this could be thought of as halving the previous
   sending rate of one packet per round-trip time.  However, because
   there is no `sending rate' associated with the SYN/ACK packet, it
   seems to us just as plausible for the packet sender to set its
   initial congestion window to one packet after the ECN-marking
   of the SYN/ACK packet, and to proceed with a cautious sending rate of
   one packet per round-trip time.  If that packet is ECN-marked or
   dropped, then the sender will wait an RTO before sending another
   packet.

It seems convincing to me, but we are also going to add a
section about worst-case scenarios of the potential bad effects
of this on other traffic, just to be clear.

- Sally
http://www.icir.org/floyd/

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

---

From: Mark Allman <[email-masked]>
Date: Thu, 19 Jan 2006 20:37:45 -0500

[speaking as an individual contributor, obviously]

Sally and I have had a bit of offline discussion about the response to a
CE-ed SYN+ACK.  My intention here is to gather my high-order points for
everyone to consider.

First, I'll react to the new text that Sally posted...

>    SYN/ACK packet, so there is no sending rate to halve.  

I don't buy this argument.  If we consider two connections ... one that
has an SYN+ACK outstanding and one that has a data segment outstanding
then they have the same rate [*].  I don't understand how there could be
"no sending rate" in either of these cases.  And, it confuses me even
more than there could be a sending rate in one case and no sending rate
in the other case.  Maybe I am missing something here.

[*] In terms of packets / second or packets / RTT --- there could be a
    bps difference because of differing packet sizes.

The way I look at this, is as follows...

  * Exactly when we get to send the first data segment if the
    SYN+ACK is CE-ed is a very minor issue.  Probably you could do
    anything and nothing awful would happen.  Likewise, you could
    probably do anything on the first retransmit of a data segment
    when cwnd=1 in the middle of a connection and nothing awful
    would happen.

  * That said, I like consistency.  I don't like special cases if
    they can be avoided.  I'd rather just uniformly apply our
    algorithms and principles as much as possible.  (That said,
    clearly there are sometimes special cases and deviating when
    there are well laid out special cases seems OK to me.)

  * Therefore, I don't like the notion from the ecnsyn I-D that when
    a SYN+ACK is CE-ed the sender gets to use a cwnd of 1 segment
    and transmit immediately because RFC3168 clearly doesn't allow
    this in other cases when there is only one segment outstanding.

  * It seems dubious to me to standardize as acceptable the practice
    of advertising ECT on a packet when the sender of that ECT has
    no intention of actually slowing down when given a CE by the
    network.

  * Is there a difference in the SYN+ACK getting CE-ed and some
    random data packet getting CE-ed when the cwnd=1?  Yes.  Are the
    differences a reason to transmit immediately?  I don't think so.
    Let me work through two differences I see ...

    (1) If the cwnd is 1 in the middle of a connection there is probably
        a reason for it.  I.e., it has been beat down to 1 segment
        because of congestion.  So, not only do we have a cwnd of 1
        segment, but we have a little more history of congestion.  With
        the SYN+ACK getting CE-ed we do not have that history.

        This is all true.  However, just because there is no visible
        history when the SYN+ACK is CE-ed doesn't mean the network is
        not in the same state as when cwnd=1 in the middle of the
        connection.  We just don't know whether the SYN+ACK just got
        unlucky or the network is in a bad state.  Basically, we're
        presenting one segment to the network and we're getting the same
        signal back.  So, it seems to me that we ought to try to do
        about the same thing.  As with other things we have
        standardized, I think that conservativeness is the right
        approach in the face of the unknown.

    (2) The other difference is that during the 3WHS the RTO is set to
        the default RTO and has nothing to do with the actual network
        path over which the connection is traversing.

        The basic idea behind ECT-ing the SYN+ACK is to get around the
        default RTO (3sec) in cases when ECN could clearly be used.  I
        think this is a very nice idea.  So, simply saying that a CE-ed
        SYN+ACK incurs the default RTO really makes the change proposed
        in this I-D pretty much a moot point.  (It still helps a little
        in that the SYN+ACK wouldn't have to be resent after 3 seconds,
        but ...)  Further, subjecting the connection to an arbitrary
        delay seems pretty dubious.

        If the two response options were "send immediately" or "send
        after the default RTO" then I'd probably lean towards the former
        because the draft would be pretty useless if the latter was
        used, IMO.

        But, there is no reason to limit ourselves to those two options.
        The ACK of the SYN+ACK gives an RTT measurement, so we can be
        much smarter.  E.g., we could actually use this RTT measurement
        to seed the RTO per (2.2) in RFC2988 and then delay for RTO
        seconds before sending the first data segment.  

        There are some people who don't like the idea of seeding the RTO
        during the 3WHS because of the discrepancy between packet sizes
        during the 3WHS and the data transfer.  This certainly makes
        some sense.  But, even if an implementation didn't want to set
        the actual RTO during the 3WHS it could impose a delay per (2.2)
        of RFC2988 on transmission of the first data segment in response
        to a SYN+ACK getting CE-ed.

  * Using either of these methods of imposing delay between getting the
    CE and sending the next data segment seems pretty consistent with
    the way that this is all handled elsewhere to me.  In particular,
    ...

      + It doesn't seem aggressive in the face of the unknown.

      + It delays transmission very similarly to RFC3168.  I.e., we
        respond to the same signal from about the same amount of load in
        about the same way in all cases.

      + It does not impose the penalty of an arbitrary default RTO on
        connections that get the SYN+ACK CE-ed.

      + It very likely improves the situation over dropping the
        SYN+ACK.

    So, my vote is for a delay that is based on RFC2988 and the measured
    RTT.

    (And, I am happy to keep discussing this if someone has another
    approach that might help me understand the difference of these cases
    and why immediate transmission is an OK special case during the
    3WHS.)

allman