Date: Sat, 17 Mar 2018 02:52:18 +0200 (EET)
From: Markku Kojo <kojo@cs.helsinki.fi>
To: Michael Tuexen <tuexen@fh-muenster.de>
cc: tcpm@ietf.org, tcpm-chairs@ietf.org
In-Reply-To: <7A3A6ECE-550B-4E5F-9D61-83C8969A7B93@fh-muenster.de>
Message-ID: <alpine.DEB.2.20.1803170143270.3710@dx6-cs-02.pc.helsinki.fi>
References: <7A3A6ECE-550B-4E5F-9D61-83C8969A7B93@fh-muenster.de>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_script-29106-1521247939-0001-2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/pAeUdVXcyq2r9lFf9sA5tzJ7ICw>
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-alternativebackoff-ecn-06
Precedence: list

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_script-29106-1521247939-0001-2
Content-Type: text/plain; format=flowed; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

Hi all,

Maybe slightly late wg last call review of=20
draft-ietf-tcpm-alternativebackoff-ecn-06.

The draft is mostly well written and clear, and it is also improved since=20
version -00 or -01 I last read it.

I believe the intention of the draft is just to allow and propose=20
experimentation using a larger multiplicative decrease factor when=20
responding to ECN indication than when responding to packet loss.

There is, however, a significant change that seem to have occured from=20
version -04 to -05 that does much more than this and is therefore crucial=20
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 =3D max (FlightSize * beta_{ecn}, 2 * SMSS)

        and

        cwnd =3D ssthresh



In my reading this text above sets a lower bound of 2 MSS for cwnd which=20
is incorrect and dangerous modification and maybe not intended to modify=20
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=3Dcwnd/2.


Instead of the above text in the draft, the draft should explicitly state=20
that when FlightSize/2 would result in ssthresh below its lower bound of =
2=20
MSS, a TCP sender must not stop decreasing cwnd. And, if more=20
ECN-signalled congestion indications arrive, the TCP sender must continue=20
reducing sending rate further (plus refer to RFC 3168 how to proceed=20
reducing the sending rate, if further ECE signals arrive).

Furthermore, the draft should be very specific on how the TCP sender=20
should act when cwnd=3Dssthresh and ECE arrives. Currently the draft=20
specifies the way how the TCP sender reduces ssthresh (and cwnd) in=20
Congestion Avoidance. According to RFC 5681, when cwnd =3D ssthresh, TCP =
is=20
not in Slow Start nor in Congestion Avoidance. Therefore, the draft=20
should be explicit on how cwnd is reduced, when cwnd=3Dssthresh.

It is true that there is (at least) one (widely deployed) incorrect=20
implementation of RFC 3168 that incorrectly sets lower bound of 2 MSS=20
for cwnd when congestion is ECN-signaled. This, however, must not be used=20
as any kind of justification for chang=EDng IETF-specified congestion=20
control principles and requirements. Instead, this draft should carefully=20
instruct implementors and those who intend to experiment with the ECN=20
modification set in this draft to ensure the TCP stack used for=20
experiments correctly implements RFC 3168 in this respect. Otherwise,=20
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=20
segment loss is detected using the retransmission timer, the TCP
congestion control does not allow one BDP of packets in flight (unless=20
BDP=3D1 MSS). Instead, cwnd is set to 1 MSS, allowing only 1 pkt in fligh=
t.

I suggest removing the text that discusses detecting segment loss using=20
the retransmission timer.

Best regards,

/Markku
--=_script-29106-1521247939-0001-2--