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

From: Bob Briscoe <[email-masked]>
Date: Fri, 30 Oct 2020 18:42:50 +0000

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 (seeAppendix 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/

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 30 Oct 2020 21:13:11 +0100

Dear Bob, Koen.
 
more below in-line, prefixed [SM].

Gesendet: Freitag, 30. Oktober 2020 um 19:42 Uhr
Von: "Bob Briscoe" <[email-masked]>
An: "tsvwg IETF list" <[email-masked]>
Cc: "iccrg IRTF list" <[email-masked]>, "TCP Prague List" <[email-masked]>, "De Schepper, Koen (Koen)" <[email-masked]>
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.
 
        [SM] This pretty much sounds like both an admission that the original requirement was so broad that is was never achievable, and, leaving a bad taste, an attempt to maker the gross hack of "slowing the CC response in TCP Prague" by the same 15ms that DualQ adds to the shallow queue to make DualQ less catastrophic at short RTT links.
IMHO the requirement should be scraped, as there is zero evidence that it is at all possible to achieve (short of relaying on oracle schedulers, or the AQM knowing the RTT of each individual flow). AND the gross hack in TCP Prague should be taken out again, and instead of trying to cure the symptoms, the root cause of the issue, dualQ's misdesign, needs to be fixed for good. The observed inequitable sharing between the two queues is caused by dualQ and needs to be fixed by dual queue. As proposed this is like re-arranging the deck chairs on the titanic. 
More to the point though, once L4S is released into the wild, nobody is going to care much for the text in the requirements section at all, as compliant behaviour is not checked by L4S's AQM. So assuming that changing this text will have any other effect, than simply making TCP Prague compliant post-hoc (by tailoring the RFC requirements to the little RTT-independence that was achievable in TCP Prague). 
       In my line of work, something like this would be considered a bad faith effort close to cheating, but it seems that here at the IETF we operate under a considerably more relaxed set of standards?
 
Regards
        Sebastian

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/[http://bobbriscoe.net/]

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 31 Oct 2020 10:38:21 +0000

Sebastian,

I am not going to respond to emails like yours that presume evil intent.
Please readjust your sad view of humanity, then re-read. If you then 
have nothing to add, pls stay silent.

The rate being inversely proportional to RTT is a feature of all 
window-fair congestion controls, including the Reno standard [RFC5168].
As explained in the rationale linked from the requirement, the only 
reason Reno (or any windw-based CC) doesn't continue to get faster at 
low /base/ RTTs is the additional queuing delay it induces.
So the more one removes this queuing delay (CoDel and PIE also suffered 
from this problem), the more the denominator tends to the base RTT.
So at the low end of the base RTT range, the inverse proportionality 
pushes the rate considerably higher.

A CC that has no RTT bias would satisfy this requirement.
But making that the requirement would have been overly prescriptive.
So we're trying to write the wording not to exclude the RTT bias that 
the Internet already works with today.
Particularly because the stability implications of moving away from the 
current Internet norm need to be treated with care.

Bob

---

From: Sebastian Moeller <[email-masked]>
Date: Sat, 31 Oct 2020 12:03:06 +0100

Dear Bob,

more below in-line, prefixed [SM2]

Gesendet: Samstag, 31. Oktober 2020 um 11:38 Uhr

An: "Sebastian Moeller" <[email-masked]>

Cc: "tsvwg IETF list" <[email-masked]>, "iccrg IRTF list" <[email-masked]>, "TCP Prague List" <[email-masked]>, "De Schepper, Koen (Koen)" <[email-masked]>

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

Sebastian,

[SM2] You just did. Make of this what you will, but please stop the posturing and get to the data and the facts.

[SM2] My view of humanity is well, thank you very much, I do not confuse team L4S  with its shady practices and acumen with humanty in general. So copud we stop these attempts at distracting from the fact that your proposed change is a fudge and a clear attempt at post-hoc making L4S RFC compliant, by adjusting the requirement instead of adjusting the L4S design. In this specific case you have my sympathy as the requirement is really impossible to full fill in a meaningful way. The only real option is to dumb down your CC response dynamis for a fixed RTT, and that is clearly a hack and in no way a solution that offers increased path-RTT independence. I am sorry that you seem to still consider your TCP Prague 15ms hack as acceptable.

[SM2] It also is a consequence of tighter control loops (smaller RTT) being more nimble ans effective than looser ones (greater RTT). The end points can not solve this issue, period. Not within our given pysical constraints that is. As I was reminded recently, the bottleneck AQM however COULD, as it has most of the relevant information available. But you opted to keep a clearly deficient AQM design and instead attempt the impossible by requiring the endpioints to effectively establish faster than light communication. That is ambitious to phraze is poitively.

[SM2] That YOUR AQM introduces, without any data shoewing why 15ms was selected. You can not argue out of the fact that the INCREASED RTT dependence at short RTTs observed in DualQ is of your own making. Pretending that this is just a case of normal RTT dependence is a bit naive, and ignoring cause and effect IMHO. Sorry that this is a bit harsh, but we have gone though this ad nauseam already and I prefer to call a spade a spade.

[SM2] Yes, but nobody forces you to COUPLE your two queues in a way that this difference results in differentisl throughput, doing so is a design mistake in DualQ, as so often an initially cute idea that showed some promise did not survive the contact with harsh reality. So far so normal, what is not normal is trying to save that clear misdesign by spreading work-arounds over different layers and fudging the requirement to make these work-arounds not violate the requirements.

[SM2] Sure, but that is made of unobtainium or rather FTL communication, not a problem resolvable in the scope of L4S, sorry.

[SM2] How about removing a requirement that SIMPLY can not be solved by the endpooints? TCP Prague tried, and as it is clear failed to do so for anything but the special case of the 15ms artifical delay introduced by DualQ. BTW has anybody tried how TCP Prague and TCP-Cubic no compete on say curvy red (or rather any AQM wirhout that brain dead coupling)?

[SM2] Could you elaborate how that is related to requiring the impossible? All of this would be funny, if you would not actually try to force down this clearly under-tested and probably unfinished experiment onto the existing internet with as little od safety measures as you can get away with. Again this soun´ds harsh as less clear wording in the past has simply been argued away or ignored.

Sebastian

Bob

--

---

From: Sebastian Moeller <[email-masked]>
Date: Sat, 31 Oct 2020 16:49:43 +0100

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

Folks,

deployment scenario (see Appendix A.1.5 for rationale).

PROPOSED:

RATIONALE:

Cheers

Bob

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Sat, 31 Oct 2020 22:33:37 +0000

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

Dear list,

Best Regards
        Sebastian

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

...

CURRENT:

      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:

RATIONALE:

Cheers

Bob

--