Re: [tcpm] WGLC for draft-ietf-tcpm-alternativebackoff-ecn-06

[Markku Kojo <[e-mail]>]

Hi all,

Maybe slightly late wg last call review of 
draft-ietf-tcpm-alternativebackoff-ecn-06.

The draft is mostly well written and clear, and it is also improved since 
version -00 or -01 I last read it.

I believe the intention of the draft is just to allow and propose 
experimentation using a larger multiplicative decrease factor when 
responding to ECN indication than when responding to packet loss.

There is, however, a significant change that seem to have occured from 
version -04 to -05 that does much more than this and is therefore crucial 
to address properly. The text and reads now in -06 as follows:


   It updates the following text in section 6.1.2 of the ECN
   specification [RFC3168] :

      The indication of congestion should be treated just as a
      congestion loss in non-ECN-Capable TCP.  That is, the TCP source
      halves the congestion window "cwnd" and reduces the slow start
      threshold "ssthresh".

   Replacing this with:

      Receipt of a packet with the ECN-Echo flag SHOULD trigger the TCP
      source to set the slow start threshold (ssthresh) to 0.8 times the
      FlightSize, with a lower bound of 2 * SMSS applied to the result.
      As in [RFC5681], the TCP sender also reduces the cwnd value to no
      more than the new ssthresh value.



And is further clarified in Section 4.3:


  and in response to an indication of an ECN-signalled congestion:

        ssthresh = max (FlightSize * beta_{ecn}, 2 * SMSS)

        and

        cwnd = ssthresh



In my reading this text above sets a lower bound of 2 MSS for cwnd which 
is incorrect and dangerous modification and maybe not intended to modify 
RFC 3168.

The lower bound for cwnd is 1 MSS. The lower bound of 2 MSS for cwnd

1) is not specified in any (standards track) RFC,
2) is against the congestion control principles for avoiding
    congestion collapse as it effectively disables a full back
    off that is a crucial requirement for all congestion control
    algorithms,
3) is in conflict with the basic principle set in Sally's ECN papers
    and in RFC 3168 itself (the original text above from RFC 3168):

    "The indication of congestion should be treated just as a
     congestion loss in non-ECN-Capable TCP."

    When Flightsize (and cwnd) is 2 MSS in non-ECN-Capable TCP and loss
    signals congestion, cwnd effectively becomes 1 MSS. That is why RFC
    3168 formulates the text: "the TCP source halves the congestion
    window "cwnd" ..."

    Note: the majority of the work and text in RFC 3168, including
    the text in RFC 2482, predates RFC 2581 that first introduced
    FlightSize. Prior to RFC 2581 all TCP CC text "halved cwnd"
    which literally meant cwnd=cwnd/2.


Instead of the above text in the draft, the draft should explicitly state 
that when FlightSize/2 would result in ssthresh below its lower bound of 2 
MSS, a TCP sender must not stop decreasing cwnd. And, if more 
ECN-signalled congestion indications arrive, the TCP sender must continue 
reducing sending rate further (plus refer to RFC 3168 how to proceed 
reducing the sending rate, if further ECE signals arrive).

Furthermore, the draft should be very specific on how the TCP sender 
should act when cwnd=ssthresh and ECE arrives. Currently the draft 
specifies the way how the TCP sender reduces ssthresh (and cwnd) in 
Congestion Avoidance. According to RFC 5681, when cwnd = ssthresh, TCP is 
not in Slow Start nor in Congestion Avoidance. Therefore, the draft 
should be explicit on how cwnd is reduced, when cwnd=ssthresh.

It is true that there is (at least) one (widely deployed) incorrect 
implementation of RFC 3168 that incorrectly sets lower bound of 2 MSS 
for cwnd when congestion is ECN-signaled. This, however, must not be used 
as any kind of justification for changíng IETF-specified congestion 
control principles and requirements. Instead, this draft should carefully 
instruct implementors and those who intend to experiment with the ECN 
modification set in this draft to ensure the TCP stack used for 
experiments correctly implements RFC 3168 in this respect. Otherwise, 
such experimental results are mostly void.


In addition, there is an incorrect statement in Sec 4.1:

  According to
  [RFC5681], when a TCP sender detects segment loss using the
  retransmission timer and the given segment has not yet been resent by
  way of the retransmission timer, the value of ssthresh must be set to
  no more of the maximum of half of the FlightSize and 2*SMSS.  The
  same equation is also used during Fast Retransmit/Fast Recovery
  [RFC5681].  As a result, the TCP congestion control only allows one
  BDP of packets in flight.  This is just sufficient to maintain 100%
  utilisation of the bottleneck on the network path.


What the text says about setting ssthresh is correct. However, if the 
segment loss is detected using the retransmission timer, the TCP
congestion control does not allow one BDP of packets in flight (unless 
BDP=1 MSS). Instead, cwnd is set to 1 MSS, allowing only 1 pkt in flight.

I suggest removing the text that discusses detecting segment loss using 
the retransmission timer.

Best regards,

/Markku