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

[Sebastian Moeller <[e-mail]>]

Bob, Koen, Wes,

please find my proposal for a clarification below, prefixed [SM]
 
 
 

Gesendet: Freitag, 30. Oktober 2020 um 19:42 Uhr
Von: "Bob Briscoe" <[e-mail]>
An: "tsvwg IETF list" <[e-mail]>
Cc: "iccrg IRTF list" <[e-mail]>, "TCP Prague List" <[e-mail]>, "De Schepper, Koen (Koen)" <[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).
[...]

       [SM]
CLARIFIED: Any protocol aiming at L4S compliance will need to account for the fact that L4S dedicated reference AQM, the dual queue coupled AQM, inflates the RTT of flows in the deep-queue by 15ms (if the AQM is configured as described in the DualQ internet draft). This will effectively lead to short RTT flows in the shallow queue staving flows in the deep queue. Since DualQ#s coupling heuristic is not designed to undo this damage, it is incumbent on L4S-compliant transport protocols to undo this damage, by artificially slowing down their congestion response "simulating" an RTT of at least that 15ms introduced by DualQ.

RATIONALE: This a) clearly names the root cause of the issue and spells out the remedy in a way that protocol implementers do not need to guess what is implied by "eliminate RTT bias" and why this is not just an generally aspirational goal, but why the 15ms hack is required for L4S to actually be deployable, as the avoidance of congestion collapse for short RTT flows in the deep queue really depends on all L4S protocols implementing that hack faithfully.
       The proposed text also removes any residual mentioning of elimination of RTT bias on first principle, since not even the designated reference protocol TCP Prague actually achieves any meaningful generic RTT de-biasing that is actually applicable in good faith to arbitrary large RTTs. 


I add, that I still consider that hack unacceptable and am of the opinion, that L4S AQM's MUST to be required not to create this situation in the first place. BUT if the WG disagrees and is fine with rolling out a clearly sub-optimal AQM with a-priori known catastrophic failure modes, then at least my proposed text should be added, to unambiguously inform protocol designers and implementers of their responsibility.


Best Regards
         Sebastian



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. 

        [SM] You realise that this is pretty much included in the definition of reducing or eliminating RTT bias, to not do harm to flows of the same protocol at larger RTTs? That requirement, I am willing to bet, was not originally written to save Reno from L4S flows (if it has, it has been exceptionally badly phrased) but really to imply that the "new" way of things is going to be better in all relevant dimensions, more RTT-independent, less re-ordering sensitive, ... This whole rationale makes me somehow think "Oceania had always been at war with Eastasia."
        Then again, this whole wiggling around and post-hoc changing of draft text, basically just confirms my statement, that generic RTT-independence can not be achieved by transport protocols, not without significant involvement of the bottleneck queue's management entity. So again, I am okay with dropping the RTT-independence requirement, as "long as the fix DualQ's 15ms hack" is still added as requirement, unless preferably the AQM design and implementation is fixed and the issue is eliminated at its source.
BUT some chairs seem to indicate that the time for real changes is over and all that is still available are small changes in the text, and so I propose this change.


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/]