Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <alpine.DEB.2.20.1803170143270.3710@dx6-cs-02.pc.helsinki.fi>
Date: Sat, 17 Mar 2018 08:17:12 +0100
Cc: Michael Tuexen <tuexen@fh-muenster.de>,
 tcpm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F5C780AF-4D6C-46F7-816C-0B540606A465@ifi.uio.no>
References: <7A3A6ECE-550B-4E5F-9D61-83C8969A7B93@fh-muenster.de>
 <alpine.DEB.2.20.1803170143270.3710@dx6-cs-02.pc.helsinki.fi>
To: Markku Kojo <kojo@cs.helsinki.fi>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/s7S0NAaSmRB5vN9SCUJXYBQ9PJY>
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-alternativebackoff-ecn-06
Precedence: list

Dear Markku,

Thank you very much for reading this!
Answers in line below:


> On Mar 17, 2018, at 1:52 AM, Markku Kojo <kojo@cs.helsinki.fi> wrote:
>=20
> Hi all,
>=20
> Maybe slightly late wg last call review of =
draft-ietf-tcpm-alternativebackoff-ecn-06.
>=20
> The draft is mostly well written and clear, and it is also improved =
since version -00 or -01 I last read it.
>=20
> 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.
>=20
> 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:
>=20
>=20
>  It updates the following text in section 6.1.2 of the ECN
>  specification [RFC3168] :
>=20
>     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".
>=20
>  Replacing this with:
>=20
>     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.
>=20
>=20
>=20
> And is further clarified in Section 4.3:
>=20
>=20
> and in response to an indication of an ECN-signalled congestion:
>=20
>       ssthresh =3D max (FlightSize * beta_{ecn}, 2 * SMSS)
>=20
>       and
>=20
>       cwnd =3D ssthresh
>=20
>=20
>=20
> 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.

Just to be clear, indeed we absolutely did not intend to change the spec =
here - however we thought we need to be clearer.

Consider the original text:
***
    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=E2=80=9D.=20
***

Because this simply says =E2=80=9Creduces=E2=80=9D about ssthresh =
without specifying in detail how to reduce it, it would seem obvious =
(due to the first sentence) that this refers to eqn. 4 in RFC 5681. =
However, if we say =E2=80=9C...set the slow start threshold (ssthresh) =
to 0.8 times the FlightSize=E2=80=9D, then we lose the lower bound. This =
is why we introduced it for ssthresh.

As for cwnd, I find the original text to be contradictory in this =
respect (unless I=E2=80=99m missing something). =E2=80=9CThe indication =
of congestion should be treated just as a congestion loss in =
non-ECN-Capable TCP. =E2=80=9C =3D> this, to me, means doing the same as =
specified in RFC 5681 - but in RFC 5681, I couldn=E2=80=99t see any text =
that allows cwnd to go below 2 MSS upon a =E2=80=9Ccongestion loss=E2=80=9D=
 (assuming this is not a timeout - where you=E2=80=99re right, our text =
wrongly quoted RFC 5681 there, but that=E2=80=99s a separate issue =
further below).

( Maybe you mean *during*, not after fast recovery? But that would be =
confusing, as cwnd is also =E2=80=9Cinflated=E2=80=9D in this phase in =
RFC 5681, which I hope we don=E2=80=99t do in response to ECE. )

However, RFC 3168, in the second sentence, beginning with =E2=80=9CThat =
is, =E2=80=9C (indicating that this is just a clarification), states =
that the TCP sources halves cwnd.


> The lower bound for cwnd is 1 MSS. The lower bound of 2 MSS for cwnd
>=20
> 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):
>=20
>   "The indication of congestion should be treated just as a
>    congestion loss in non-ECN-Capable TCP."
>=20
>   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" =E2=80=A6"

See above, regarding this text. We certainly don=E2=80=99t want to =
change these principles but tried to be correct about what should =
happen, and found the quoted text here to be contradictory.


>   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.

I know that, and I thought that this is the reason for the problem with =
this text (due to updates of the non-ECN CC text).


> 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).

Technically this makes sense to me, but I=E2=80=99m not currently =
reading RFC 3168 this way.


> Furthermore, the draft should be very specific on how the TCP sender =
should act when cwnd=3Dssthresh 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 =3D ssthresh, TCP =
is not in Slow Start nor in Congestion Avoidance. Therefore, the draft =
should be explicit on how cwnd is reduced, when cwnd=3Dssthresh.

Why? RFC 5681 states =E2=80=9CWhen cwnd and ssthresh are equal, the =
sender may use either slow start or congestion avoidance.=E2=80=9D - so =
if you're an implementer, this basically tells you that you have to make =
a decision on your own for the cwnd =3D=3D sthresh case. We specify how =
to behave when you=E2=80=99re in congestion avoidance - thus it depends =
on the decision you=E2=80=99ve taken for this case.


> 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=C3=ADng 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.

Maybe the person behind this implementation was as confused by the RFC =
3168 as I am =E2=80=A6 clearly we didn=E2=80=99t intend to change the =
principles.


> In addition, there is an incorrect statement in Sec 4.1:
>=20
> 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.
>=20
>=20
> 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=3D1 MSS). Instead, cwnd is set to 1 MSS, allowing only 1 pkt in =
flight.
>=20
> I suggest removing the text that discusses detecting segment loss =
using the retransmission timer.

Good catch, thanks!

Cheers,
Michael