Early Review of draft-livingood-low-latency-deployment-07
review-livingood-low-latency-deployment-07-tsvart-early-kuehlewind-2024-11-19-00

Thanks for the well-written and clear document. I have no concern about
publication on the ISE track, however, I have a couple of mostly small (maybe
one more mayor) comments for consideration below.

1) One potentially more mayor comment on section 1.1 and 3.3 first:
I disagree a bit with this characterisation of queue building traffic. It is
true that small transmissions usually don’t build a queue, however, the whole
point about L4S is that no transmission would need to build a queue. Having
there longer transmission building a queue as a tool to maximise utilisation is
simply a consequence of the currently deployed congestion control and we cannot
just deploy new congestion controls easily because of fairness/starving issues
- that’s why we need two queues and separation.

Similar the recommendation in section 3.3 is not fully aligned. Again, the goal
of L4S is effectively that in future all traffic uses the low latency queue,
however, given they also change the congestion control respectively. So that’s
the real message, if you don’t change you congestion control and run
long-lasting flow on the L4S queue, your performance will actually be worse.

2) Minor comment on also section 1.1
I don’t really follow why the trails are mentioned here (already)…?

3) Another small comment on section 1.2
There is also a trust issue with hierarchical QoE that is not mentioned here at
all: if one is strictly better than the other why would anybody choose to use
the worst service (independent of their real needs).

4) On section 3.4
Is this really a choice between L4S and NQB? I think you can effectively do
both and then your treatment really depends on what is deployment in the
network. But that’s something you might not necessarily know in advance at the
application. The only thing to consider maybe is that you should not set the
NQB code point if you application would be queue building in the absence of an
L4S queue. But in this sense these two signals are actually to some extend
orthogonal.

5) On section 4.3
I guess there are still boxes that bleach the whole ToS field rather than just
the DiffServ code point but at least that doesn’t really break anything; only
that ECN is not usable. So I would say that while it may or may not be correct
that bleaching for ECN is “unlikely to be any issues”, it is not entirely
unlikely to happen.

6) Security consideration:
Thanks for writing this clearly down: however the advise at the end says “it
seems prudent to implement Queue Protection” which seems a bit to strong for me
given the discussion. Maybe rather replace “prudent” with “reasonable” or even
something weaker?

7) Finally, I recommend to rename the section “Regulatory Considerations” to
“Network Neutrality Considerations” as the section does not appear to talk
about any other regulatory considerations.

8) Minor nits that I happen to find:
Sec 3.4: Latency-sensitive flows that need more bandwidth are congestion
   controlled, and identified via ECN marking. -> remove comma
Sec 4.1: funcyion
Sect 4.3.1: s/mark on an end to end basis/mark on an end-to-end basis/
Sec 8: “Generally speaking, In the” -> s/In/in/