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/