Re: [tsvwg] start of WGLC on L4S drafts

[Bob Briscoe <[e-mail]>]

Luca, see [BB]

On 15/10/2021 18:02, Luca Muscariello wrote:
>
>
> On Wed, Oct 13, 2021 at 12:03 AM Bob Briscoe <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Sebastian,
>
>     Sorry - just noticed I missed this email at the time. See [BB]...
>
>     On 21/09/2021 21:54, Sebastian Moeller wrote:
>     > Hi Bob,
>     >
>     >
>     >
>     >> On Sep 20, 2021, at 18:40, Bob Briscoe <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >>
>     >> Alex, Gorry, [Sry, just discovered I didn't click end on this]
>     >>
>     >> In "all of a user's applications can shift" the word "can" is
>     important.
>     >> Similarly, in "The L4S architecture is intended to enable all
>     Internet applications to transition" the word "enable" is important.
>     >>
>     >> Neither statement was meant to imply that all applications
>     would move, or should move, just that they would all be _able_ to.
>     >> These statements are primarily intended as counterpoints to the
>     commonly held view that low latency comes from priority scheduling
>     (e.g. via differentiated service) so low latency can only be
>     provided for a subset of traffic, because if all packets requested
>     higher priority, there would be no difference to any packet's latency.
>     >       [SM] Given that at the core of the L4S reference AQM there
>     sits a (conditional) priority scheduler*, I fail to see how L4S'
>     low latency does not come from priority scheduling? Also in L4S
>     low latency can only be provided to a subset of traffic, namely
>     flows that are well behaved and ECT(1)-marked (given the shared
>     queue design, one bad apple in the L-queue can affect
>     latency/throughput for all flows). I am not sure whether L4S
>     really is contrary to the "commonly held view" here, sure the
>     details differ a bit, but at its core it seems rather similar to
>     traditional techniques for low latency.
>
>     [BB] You say 'L4S low latency can *only* be provided to a subset' (my
>     emphasis), but the word 'only' is wrong.
>     That is the point. L4S low latency /can/ be provided to all traffic.
>
>     Yes, L4S low latency /is/ only provided to flows that are
>     well-behaved
>     and ECT(1) marked, but all traffic /can/ behave smoothly without
>     losing
>     out, and all traffic /can/ use ECT(1) without losing out.
>
>     The priority scheduler really is not at the core.
>     * Consider an L4S FQ scheduler like FQ-CoDel with the ce_threshold
>     parameter applied to ECT(1) traffic. There is no priority
>     scheduling but
>     all traffic can still have very low latency.
>     * Similarly, an L4S DualQ Coupled AQM can work with any scheduler
>     that
>     provides isolation, for instance the Time-Shifted FIFO. Scheduling
>     priority is not 'at the core', 'cos it's not even necessary. We only
>     ended up choosing a priority scheduler because it gave slightly
>     better
>     tail latency.
>
>     The real core of L4S is scalable congestion control. That is the
>     difference that allows even capacity-seeking traffic to also maintain
>     consistently very low latency. It's easier to see in the L4S FQ
>     example,
>     that it's what keeps a flow's latency down. Not the scheduler.
>
>     If TCP had been designed with a scalable congestion control from the
>     start, we would have had L4S with no need for a scheduler at all. The
>     scheduler is primarily a transition mechanism, to isolate from
>     Classic
>     traffic. But no traffic /needs/ to be Classic, it's just how "stuff
>     happened".
>
>
> I do not think this is true in this specific case.
> There is an advantage in terms of goodput for applications to use
> loss-based congestion control and create bigger queues (in
> absence of isolation).

[BB] This may be true in the short term for non-latency sensitive bulk 
traffic, especially over variable capacity (e.g. radio) links where 
buffered packets can fill newly available capacity while the e2e 
congestion control catches up.

Nonetheless, there is also the unscalable aspect of loss-based 
congestion control where, as flow rate scales, it takes longer and 
longer (minutes) to recover after each loss [RFC3649]. As was pointed 
out in footnote 6 of [Jac88], the noise sensitivity gets worse as flow 
rate scales. Meaning, even if there's a very low level of transmission 
losses or new flows arriving, a flow keeps getting knocked down by each 
noise event, while it's slowly trying to regain its previous position.

It's possible that some new approach will get out of that unscalable 
rut, but it's been quite resistant to solutions so far. BBRv2 has 
already had to reinstate a capped dependence on loss probability, in 
order to remain backward compatible with the legacy of loss-based 
congestion controls. The setting of that cap will have to keep being 
reduced in order to scale flow rate, so it is trapped in the same noise 
sensitivity problem.

I don't know whether bulk flows will prefer to continue to use the 
classical approach with more buffering, or the scalable approach with 
frequent control signals. I'm just saying it's not as clear-cut as you 
make out.

[Jac88] Van Jacobson and Michael J. Karels. Congestion
Avoidance and Control. Technical report, Lau-
rence Berkeley Labs, November 1988. (a slightly
modified version of the original published at SIG-
COMM in Aug’88)


> Unless these applications are policed one way or the other
> it is hard to create incentives to move towards protocols that
> generate little queuing. Isolation is one such policy as the reward
> is immediate.

[BB] When you have scalable congestion controls that fill capacity with 
consistently very low queueing, you can just use them (without policing) 
whether you need low latency, high throughput or both.

As a fairly close analogy, can you imagine any individual or company 
gaming a PIE AQM to induce more latency on their own flow, in order to 
impose more latency on others in the same household?

Policing hasn't even been necessary for 'TCP-friendliness' between 
application flows within a household, where there is bandwidth to gain. 
I don't know whether policing will be necessary for 'latency 
friendliness'. Maybe it will at first while there are people around who 
don't understand that there's nothing to gain.

My prediction, FWIW: I suspect that some policing within some paths 
(e.g. in DOCSIS links) will be enough at first to keep globally deployed 
code disciplined, whether or not it's actually running over a path with 
policing. I doubt policing will be necessary longer term, but we will 
have it if we need it. So nothing is hanging on who predicts this 
correctly.

Or are you saying that we should never allow anyone to even attempt to 
have low latency in shared queues in case it requires the complexity of 
per-flow policing?
But instead we should only ever allow per-flow queuing for low latency, 
which is somewhat more complex than per-flow policing anyway.
I hope you appreciate that avoiding the possible risk of a little 
complexity by requiring more complexity is broken logic.

> There is also a major implication between priority or scheduling
> as an isolation mechanism: for the latter there is no need to
> allocate a bit in the network header to identify traffic types.

[BB] I don't understand what you have in mind here. Pls explain more fully.



Bob


>
>
>
>
>
>     Bob
>
>     >
>     > Regards
>     >       Sebastian
>     >
>     >
>     > *)
>     https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-19
>     <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-19>:
>     > "In this case it would not be appropriate to call the queue an L4S
>     >     queue, because it is shared by L4S and non-L4S traffic. 
>     Instead it
>     >     will be called the low latency or L queue.  The L queue then
>     offers
>     >     two different treatments:
>     >
>     >     o  The L4S treatment, which is a combination of the L4S AQM
>     treatment
>     >        and a priority scheduling treatment;
>     >
>     >     o  The low latency treatment, which is solely the priority
>     scheduling
>     >        treatment, without ECN-marking by the AQM."
>     >
>     >
>     >
>     https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch-10
>     <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch-10>:
>     > "The tension between prioritizing L4S and coupling the
>     >         marking from the Classic AQM results in approximate per-flow
>     >         fairness.  To protect against unresponsive traffic in
>     the L4S
>     >         queue taking advantage of the prioritization and
>     starving the
>     >         Classic queue, it is advisable not to use strict
>     priority, but
>     >         instead to use a weighted scheduler (see Appendix A of
>     [I-D.ietf-tsvwg-aqm-dualq-coupled])."
>     >
>     >
>     https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled
>     <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled>
>     > "Classic traffic needs to build a large queue to prevent under-
>     >     utilization.  Therefore a separate queue is provided for L4S
>     traffic,
>     >     and it is scheduled with priority over the Classic queue. 
>     Priority
>     >     is conditional to prevent starvation of Classic traffic."
>     >
>     > I ignore the yarn spun in those drafts, why this prioritization
>     would only result in latency but not longer-time-scale throughput
>     prioritization, because Pete's data show that for quite a number
>     of realistic traffic patterns DualQ fails to arbitrate capacity
>     equitably between the two queues.
>     >
>     >
>     >
>     >> I've made a note to myself to make it clear that this is not an
>     intention that all applications will transition, rather it is an
>     intention not to prevent any application from transitioning.
>     >>
>     >>
>     >> Bob
>     >>
>     >> On 02/09/2021 19:26, [e-mail]
>     <mailto:[e-mail]> wrote:
>     >>> Hi Gorry, tsvwg;
>     >>>
>     >>>
>     >>> See inline [AB]
>     >>>
>     >>>
>     >>>
>     >>> On Thursday, August 12, 2021, 11:23:49 AM GMT+1, Gorry
>     Fairhurst<[e-mail] <mailto:[e-mail]>> wrote:
>     >>>
>     >>> ---
>     >>> 1b) Issue: I’d also quibble with: “so that all of a user's
>     applications
>     >>> can shift to it when their stack is updated.“ - again, is the
>     word “all”
>     >>> really necessary or correct here?
>     >>> ---
>     >>>
>     >>> [AB]
>     >>> Not  answering your point, but related:
>     >>>
>     >>> L4s-arch has at the very start the following: “The L4S
>     architecture is intended to enable   _all_ Internet applications
>     to transition away from congestion control algorithms that cause
>     queuing delay, to a new class of congestion controls that induce
>     very little queuing, aided by  explicit congestion signaling from
>     the network. “
>     >>>
>     >>>
>     >>>   There are two quite different end states here:
>     >>>
>     >>> * An internet in which there are, end-to-end, two classes of
>     traffic on an ongoing basis.
>     >>>
>     >>> * An internet in which nearly all traffic has transitioned to
>     L4S, remaining non-L4S traffic being supported on a
>     backwards-compatibility basis
>     >>>
>     >>> As I understand it, if L4S is deployed, either of these could
>     be possible end states. At present it is not clear that all use
>     cases could migrate (eg, long RTT traffic)
>     >>>
>     >>>
>     >>> It seems like it would be a good idea for the draft to make clear:
>     >>> * That either of these end states are possible
>     >>> * What the formal position of the WG would be if the drafts
>     are accepted, IE what decision has been made (or left for later)
>     regarding the desired end state.
>     >>>
>     >>>
>     >>> regards,
>     >>>
>     >>> Alex
>     >>>
>     >> --
>     >> ________________________________________________________________
>     >> Bob Briscoehttp://bobbriscoe.net/ <http://bobbriscoe.net/>
>     >>
>
>     -- 
>     ________________________________________________________________
>     Bob Briscoe http://bobbriscoe.net/ <http://bobbriscoe.net/>
>

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