Re: [tsvwg] Review comments on a careful read of the L4S ID

[Sebastian Moeller <[e-mail]>]

Hi Bob,



> On May 7, 2021, at 23:35, Bob Briscoe <[e-mail]> wrote:
> 
> Sebastien,
> 
> On 07/05/2021 15:45, Sebastian Moeller wrote:
>> 	[SM2] But QUICK is missing quite a number of the other requirements for a L4S-compatible protocol, so can clearly not be used for open-internet testing at the current time, no?
> 
> [BB] What exactly do you believe is missing?

	Since so far all that QUIC has implemented is a back-channel for the received ECN code points at the receiver, I naively? assume the following laundry list is not confirmed to be operational:

   o  A scalable congestion control MUST be capable of being replaced by
      a Classic congestion control (by application and/or by
      administrative control).  If a Classic congestion control is
      activated, it will not tag its packets with the ECT(1) codepoint
      (see Appendix A.1.3 for rationale).

   o  As well as responding to ECN markings, a scalable congestion
      control MUST react to packet loss in a way that will coexist
      safely with Classic congestion controls such as standard Reno
      [RFC5681], as required by [RFC5033] (see Appendix A.1.4 for
      rationale).

   o  In uncontrolled environments, monitoring MUST be implemented to
      support detection of problems with an ECN-capable AQM at the path
      bottleneck that appears not to support L4S and might be in a
      shared queue.  Such monitoring SHOULD be applied to live traffic
      that is using Scalable congestion control.  Alternatively,
      monitoring need not be applied to live traffic, if monitoring has
      been arranged to cover the paths that live traffic takes through
      uncontrolled environments.

      The detection function SHOULD be capable of making the congestion
      control adapt its ECN-marking response to coexist safely with
      Classic congestion controls such as standard Reno [RFC5681], as
      required by [RFC5033].  Alternatively, if adaptation is not
      implemented and problems with such an AQM are detected, the
      scalable congestion control MUST be replaced by a Classic
      congestion control.

      Note that a scalable congestion control is not expected to change
      to setting ECT(0) while it transiently adapts to coexist with
      Reno.

      See Appendix A.1.5 and [I-D.ietf-tsvwg-l4sops] for rationale.

   o  A scalable congestion control MUST reduce 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.6
      for rationale).

   o  A scalable congestion control SHOULD remain responsive to
      congestion when typical RTTs over the public Internet are
      significantly smaller because they are no longer inflated by
      queuing delay.  It would be preferable for the minimum window of a
      scalable congestion control to be lower than 1 segment rather than
      use the timeout approach described for TCP in S.6.1.2 of [RFC3168]
      (or an equivalent for other transports).  However, a lower minimum
      is not set as a formal requirement for L4S experiments (see Appendix A.1.7
      for rationale).

   o  A scalable congestion control's loss detection SHOULD be resilient
      to reordering over an adaptive time interval that scales with
      throughput and adapts to reordering (as in [RFC8985]), as opposed
      to counting only in fixed units of packets (as in the 3 DupACK
      rule of [RFC5681] and [RFC6675], which is not scalable).  As
      packet rates increase (e.g., due to new and/or improved
      technology), congestion controls that detect loss by counting in
      units of packets become more likely to incorrectly treat
      reordering events as congestion-caused loss events (see Appendix A.1.8
      for further rationale).  This requirement does not
      apply to congestion controls that are solely used in controlled
      environments where the network introduces hardly any reordering.

   o  A scalable congestion control is expected to limit the queue
      caused by bursts of packets.  It would not seem necessary to set
      the limit any lower than 10% of the minimum RTT expected in a
      typical deployment (e.g. additional queuing of roughly 250 us for
      the public Internet).  This would be converted to a number of
      packets under the worst-case assumption that the bottleneck link
      capacity equals the current flow rate.  No normative requirement
      to limit bursts is given here and, until there is more industry
      experience from the L4S experiment, it is not even known whether
      one is needed - it seems to be in an L4S sender's self-interest to
      limit bursts.


https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-34#section-7 seems to confirm that QUIC currently implements rfc3168 style CE response, with the possibility of exchanging the sender CC algorithm. But I see no L4S "module" for quic. If you know where I can find the implementation of the above laundry list for QUIC,  point to the right UL, please.


> 
> If you add a scalable congestion control at the sender, by default from v1 of the IETF QUIC protocol, it provides the necessary accurate ECN feedback (and of course loss feedback) with no alterations required to the protocol.

	[SM] Potentially a nomenclature mismatch, when I say protocol, I do not speak only about the on-the-wire headers, but also the specification what to do with the received information so I include the CC algorithm as part of the protocol. If protocol is the wrong word, I apologize. But yeah we seem to agree, to fulfill the L4S protocol requirements QUIC needs to grow a compliant L4S-CC, in other words currently that part is missing in QUIC.


> See for instance https://github.com/qdeconinck/picoquic/tree/quic-prague where Quenten De Coninck added the Prague CC as it was at the time to QUIC in a couple of days at a hackathon (not maintained since, but it at least proved that QUIC had all the necessary facilities).

	Well, see, IMHO current TCP Prague does not fully fulfill the L4S protocol-requirements, so I am not convinced, that an abandoned port of an older version of TCP Prague without either the the WIP RTT-debias ot rfc3168 detection/fall-back components, will count as proof that QUIC is an L4S-compatible protocol today. I do not claim that making n L4S-aware QUIC version is impossible, but simply that current QUIC is not that version (yet?).

Best Regards
	Sebastian

P.S.: I must be missing something here...


> 
> 
> 
> Bob
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>