Re: [tsvwg] https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01#NewThinking

["Livingood, Jason" <[e-mail]>]

Thanks Sebastian - will incorporate into an update on which I am working right now. Making significant changes in response to each of your recommendations.


Jason


On 3/19/23, 06:10, "tsvwg on behalf of Sebastian Moeller" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> on behalf of [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:




Dear list,




[SM] I started to look at https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01__;!!CQl3mcHX2A!AmULDT9h4izDsq8Uv5SzAjBiTa3_f8SR8jQk-CGMmG8BQerRUvygrpILGdxwk0uDMgf5VInlAeUNKIzbR5tVXI_F$ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01__;!!CQl3mcHX2A!AmULDT9h4izDsq8Uv5SzAjBiTa3_f8SR8jQk-CGMmG8BQerRUvygrpILGdxwk0uDMgf5VInlAeUNKIzbR5tVXI_F$> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01__;!!CQl3mcHX2A!AmULDT9h4izDsq8Uv5SzAjBiTa3_f8SR8jQk-CGMmG8BQerRUvygrpILGdxwk0uDMgf5VInlAeUNKIzbR5tVXI_F$ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01__;!!CQl3mcHX2A!AmULDT9h4izDsq8Uv5SzAjBiTa3_f8SR8jQk-CGMmG8BQerRUvygrpILGdxwk0uDMgf5VInlAeUNKIzbR5tVXI_F$>> . Now this is on the Informational track and hence hard to argue with. However it seems to contain imprecise descriptions that I would prefer not to find in any RFC independent of the document track:




https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01&gt;>*NewThinking__;Iw!!CQl3mcHX2A!AmULDT9h4izDsq8Uv5SzAjBiTa3_f8SR8jQk-CGMmG8BQerRUvygrpILGdxwk0uDMgf5VInlAeUNKIzbR2wU7Xwo$ 
"The Introduction says "Furthermore, unlike with bandwidth priority on a highly/fully utilized link, low latency using these new approaches is not a zero sum game - everyone can potentially have lower latency at no one else's expense." But this bears a bit more discussion to understand more fully."




[SM] This seems to misrepresent the mechanism L4S is build on, the dualQ coupled AQM, in a sense the reference L4S AQM, is described as a "conditional priority scheduler" and configure to have a rate share for the non-LL:LL-queue in the 1:10 (current Linux implementation IIRC) to 1:16 (rfc9332). This priority scheduler now is combined with a heuristic that aims at making the likelihood of that priority scheduling actually become visible rare. But "rare" is not never, and the resource distribution problem of selecting a packet for the immediate transmission seems to be a zero sum game, L4S or not L4S.




[SM] Here a wikipedia explanation of zero-sum game:
"Zero-sum game is a mathematical representation in game theory and economic theory of a situation which involves two sides, where the result is an advantage for one side and an equivalent loss for the other.[1] In other words, player one's gain is equivalent to player two's loss, therefore the net improvement in benefit of the game is zero."




[SM] For any given "transmit time" you ca picke a packet from either queue (or introduce a stall, but L4S does not do that)), this is very much a zero-sum game by the definition above.




[SM] Let's move on:




https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01&gt;>*NewThinking__;Iw!!CQl3mcHX2A!AmULDT9h4izDsq8Uv5SzAjBiTa3_f8SR8jQk-CGMmG8BQerRUvygrpILGdxwk0uDMgf5VInlAeUNKIzbR2wU7Xwo$ 
"4S does *not* provide low latency in the same way as previous technologies like DiffServ (QoS). That prior QoS approach used packet prioritization, where it was possible to assign a higher relative priority to certain application traffic, such as Voice over IP (VoIP) telephony.




[SM] Again, given the right conditions, L4S will do exactly what is claimed here it would do not, e.g. when a short RTT L4S flow shares a link with a long RTT conventional-TCP flow.








https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01&gt;>*NewThinking__;Iw!!CQl3mcHX2A!AmULDT9h4izDsq8Uv5SzAjBiTa3_f8SR8jQk-CGMmG8BQerRUvygrpILGdxwk0uDMgf5VInlAeUNKIzbR2wU7Xwo$ 
"This approach could provide consistent and relatively low latency by assigning high priority to a partition of the capacity of a link, and then policing the rate of packets using that partition. For example, on a 10 Mbps link, a high QoS priority could be assigned to VoIP with a dedicated capacity of 1 Mbps of the 10 Mbps link capacity. The other 9 Mbps would be available to lower QoS priority, such as best effort general Internet traffic that was not VoIP.¶




[SM] You realize that priority schedulers nowadays offer things like "rate-borrowing" where unused capacity of a higher priority class can be used by lower classes if the higher class does not use-up its allotment? So in this example the traditional QoS priority hierarchy offers exactly the same performance as the L4S approach, the single VoIP stream sees minimal delay and the remaining traffic gets ~9.9Mbps and there are no transmission stalls.








https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01&gt;>*NewThinking__;Iw!!CQl3mcHX2A!AmULDT9h4izDsq8Uv5SzAjBiTa3_f8SR8jQk-CGMmG8BQerRUvygrpILGdxwk0uDMgf5VInlAeUNKIzbR2wU7Xwo$ 
"But even when QoS was used in this manner, the latency may have been relatively good but it was not ultra low latency of the sort that low latency networking (NQB and L4S) can deliver. As well, that QoS approach is to some extent predicated on an idea that network capacity is very limited and that links are often highly utilized. But in today's Internet, it is increasingly the case that there is an abundance of capacity to end users, which makes QoS approaches ineffective in delivering ever-lower latency.¶"




[SM] This example is counter-intuitve and potentially mis-leading, a VoIP flow of typically ~100Kbps well-paced packets when scheduled in a weighted priority of 1:9 Mbps as the sole member in that priority class, will see pretty much only the delay for the currently transmitted packet, and if the link technology does support pre-emption, it might not even see that delay.
[SM] This technically is "as low as queueing delay can go" that is piping that VoIP flow though an L4S scheduler/AQM instead can offer no advantage at all, once delay is minimal it is minimal, and hence "ultra-low latency". (And I add, that VoIP flow is also unlikely to respond to L4S-style marking making it risky to sort it into the LL-queue).








https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01&gt;>*NewThinking__;Iw!!CQl3mcHX2A!AmULDT9h4izDsq8Uv5SzAjBiTa3_f8SR8jQk-CGMmG8BQerRUvygrpILGdxwk0uDMgf5VInlAeUNKIzbR2wU7Xwo$ 
"The result, as noted in the prior section, has been the role of dual queue networking. With these approaches, the new low latency packet processing queue is introduced on one or more links on the end-to-end path. The internal L4S queuing may still use a sort of internal prioritization, but this is not QoS in the typical sense because this is happening on an extremely short timescale - sub-round trip time (so microseconds or a few milliseconds)."




[SM] This does not seem to be a logical argument, prioritization really just means to decide "what to do next" and hence is not defined as requiring a minimal timescale, so just because L4S has short queues does not make it use anything else than prioritization when giving L4S traffic a higher probability of shorter sojourn times.








https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment-01&gt;>*NewThinking__;Iw!!CQl3mcHX2A!AmULDT9h4izDsq8Uv5SzAjBiTa3_f8SR8jQk-CGMmG8BQerRUvygrpILGdxwk0uDMgf5VInlAeUNKIzbR2wU7Xwo$ 
"A more important and impactful force at play is the rapid congestion signals that are exchanged that will cause a sender to dynamically yeild to other traffic (as if the other traffic had no QoS priority, which it does not) - which can be thought of as back pressure to signal the sender to backoff prior to packetloss occuring.¶"




[SM] This seems to be at least irrelevant for the VoIP example from the same section. Also in traffic if I yield to other traffic at an intersection, I will stop immediately, but an L4S flow will still require a full RTT worth of time before it can react and the changed load hits the bottleneck. And yes that non-LL traffic has 1:10 or 1:16 priority, L4S just does a decent job of not engaging that part of its design under some typical? conditions (as long as users do not start mixing flows with large differences in RTT, or there is not too much under-responsive but paced traffic in the LL-queue, think 90 parallel VoIP flows of 100 Kbps each in the 10Mbps link example above).




[SM] Nitpick: yield instead of yeild




Again this is targeted as Informational and intended to document Comcast's recommendations, which might well be built on what the text describes, yet it would be helpful to make sure that technology is described in objective language that is free from bias. 




P.S.: The L4S RFC's clearly state that L4S is built upon conditional priority scheduling between its two queues, so it seems rather surprising to claim that it does not. It is not hard to describe its mechanism in this draft in a way, that is correct and still shows how this design has the potential of higher utility than a strawman of a fixed prioritity assignment, but it will require an example where L4S actually deliver over the traditional hierarchical prioritization method.