Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative RTT Bias Text

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Sebastian,

It was never our intent to develop the Congestion Control itself, as it was not in our interest (as a network provider). There are plenty of bright people that can develop a Prague-compliant CC that will benefit their business (and at least comply to the safety measures). From the start we realized that the small buffer is a potential safety issue for the typical r~=1/RTT congestion controls (also confirmed by our early tests and later by Pete’s tests too). We hoped by showing that (once one puzzles out how) making a CC RTT independent for the unsafe range (small RTTs) is an easy obvious hack. To please you, we even made a “Sebastian-version” with f(rtt)=rtt+15ms that only removes the RTT benefit from the DualQ (one of your main complaints), and behaves further as a Classic RTT dependent flow. The Sebastian-version solves the safety issue and your fairness issue, but is not our preferred version. We like more the one that solves the safety issue with f(rtt)=max(rtt, 15ms), and still allows L4S to benefit from the lower delay in all other cases.

Then thanks to your insisting to realize literally what we have written, we realized that the text was indeed too strict if read out of the larger context. In the context of the safety requirements section, we never wanted to enforce RTT fairness for flows with a bigger than the reference RTT, as they don’t pose a safety issue (it is a reality for all longer RTTs today, partially solved by Cubic already), and the quoted text could indeed be interpreted that way out of the larger context. Blindly trying to implement RTT independence for larger RTTs could even make it unsafe, if not done correctly. Of course, if wanted and beneficial, others are free to further optimize.

So I hope you understand now why we want to fix this text (and don’t see this as a failure), and hope you are ok too, to keep this safety requirement to the safety aspect only. If you think the text is still not clearly representing the safety requirement of the RTT independence aspect, then your suggestions are very welcome.

As to your request to let the AQM make flows RTT independent, that is unfortunately impossible without knowing the RTT of each packet or identifying and treating the flows individually. So can you explain why you claim that what actually is easy (RTT-indep CC) is impossible and why you insist on what is impossible (RTT-indep AQM) should be done instead???

Thanks and regards,
Koen.


From: Sebastian Moeller <[e-mail]>
Sent: Saturday, October 31, 2020 4:50 PM
To: Bob Briscoe <[e-mail]>
Cc: tsvwg IETF list <[e-mail]>; iccrg IRTF list <[e-mail]>; TCP Prague List <[e-mail]>; De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>
Subject: Aw: [tsvwg] ecn-l4s-id: Proposed Changed to Normative RTT Bias Text

Dear list,

please note that both of these "requirements" hedge against the fact that RTT independence is almost impossible to achieve from the endpoints (as it is a consequence of buffering at the bottleneck), originally bzy stating "as wide a range of RTTs as possible" (which given the phisical constraints in reality is equal to the empty set). Replacing that non-requirement with a differently worded version ("as much as possible") does not change anything substantially, except for making TCP Prague appear less of a failure.
IMNHO this requirement for an L4S compatible transport, should be replaced with a requirement for an L4S compliant AQM (as it is limited queueing at the bottleneck that causes most the issue) MUST at least perform as well as a dumb FIFO, a mark which DualQ at short RTTs misses badly. But I guess, a no regressions against the status quo requirement, will probably not apply to L4S.

Best Regards
        Sebastian


Gesendet: Freitag, 30. Oktober 2020 um 19:42 Uhr
Von: "Bob Briscoe" <[e-mail]<mailto:[e-mail]>>
An: "tsvwg IETF list" <[e-mail]<mailto:[e-mail]>>
Cc: "iccrg IRTF list" <[e-mail]<mailto:[e-mail]>>, "TCP Prague List" <[e-mail]<mailto:[e-mail]>>, "De Schepper, Koen (Koen)" <[e-mail]<mailto:[e-mail]>>
Betreff: [tsvwg] ecn-l4s-id: Proposed Changed to Normative RTT Bias Text
Folks,

The co-authors of ECN L4S ID have been reviewing the correctness of the normative 'Prague' requirements.
    See https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3
This is the first of 2 emails, about 2 of the requirements that we think ought to be reworded a little.

If you agree with the rationale, but think the new wording still doesn't capture the requirement well, pls suggest sthg better.
If you disagree with the rationale, pls discuss.


4.3.  Prerequisite Congestion Response

...

CURRENT:

   o  A scalable congestion control MUST reduce or eliminate RTT bias

      over as wide a range of RTTs as possible, or at least over the

      typical range of RTTs that will interact in the intended

      deployment scenario (see Appendix A.1.5<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#appendix-A.1.5> for rationale).

PROPOSED:
A scalable congestion control MUST eliminate RTT bias as much as possible in the range between the minimum likely RTT and typical RTTs expected
in the intended deployment scenario  (see Appendix A.1.5 for rationale).

RATIONALE:
1/ "eliminate as much as possible" is stronger than "reduce or eliminate".
2/ This requirement was motivated by 'do no harm to others' relative to existing standard (RFC5681 Reno) congestion control. So there is no need to mandate that an L4S implementer does no harm to themselves, which window-based congestion controls tend to do at higher RTT. Of course, this doesn't preclude implementers reducing or eliminating RTT bias for larger than typical RTTs, but it removes any requirement to do so.

Cheers


Bob


--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/