[tsvwg] A review of draft-ietf-tsvwg-l4s-arch-09

[Vidhi Goel <[e-mail]>]

Dear L4S authors,

I have a few comments on the architecture draft.

1. Section 4, Protocols
 >> much more frequent signals--too often to require an equivalent
    excessive degree of drop from non-ECN flows;

I am a little confused by this statement. Is it saying that the frequent signaling in L4S is too often that it is equivalent to the “drop” signal in case of non-ECN flows? Or does the too often ECN signal requires an a certain degree of drop from non-ECN? 
I think it means the former but still bit a confusing to read.

Similar question about the second bullet, too soon for L4S here means it will result in the same effect as drop for non-ECN, right?
 >> immediately tracking every fluctuation of the queue--too soon
    to warrant dropping packets from non-ECN flows.

2. Section 4, Network
  >> Then the Classic
     AQM such as CoDel or PIE is applied to non-ECN or ECT(0) packets,
     while the shallow threshold is applied to ECT(1) packets, to give
     sub-millisecond average queue delay.
If the bottleneck with CoDel has both classic and L4S packets in the queue at the same time, then a “shallow threshold” for L4S can’t guarantee sub-ms queue delay, right?

3. Section 4, Hosts
    >> Also the L4S ECN part of
    BBRv2 [I-D.cardwell-iccrg-bbr-congestion-control <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch-09#ref-I-D.cardwell-iccrg-bbr-congestion-control>] is a scalable
    congestion control intended for the TCP and QUIC transports,
    amongst others.

The BBR draft has no mention of L4S ECN so far. Are we expecting an updated BBR draft and reference? There is another reference in Section 5.2. 

4. Section 5.1
    >> The consequent smaller amplitude sawteeth
    fit between a very shallow marking threshold and an empty
    queue, so queue delay variation can be very low, without risk
    of under-utilization.

Is there a description of what "very shallow marking threshold” means in terms of time or anything else? I think it would be good to quantify this term, even if it is approximate.

5. Section 5 has a lot of redundant info, perhaps it can be shortened. Some of it can be combined with Section 3 - terminology.

6. Section 5.2
   >> The L4S architecture does not require the IETF to commit to
    one approach over the other, because it supports both, so that
    the market can decide.

Minor suggestion: s/market/industry


I would really appreciate if you could re-organize Section 5 as some of the content in that section was previously covered. If needed, I can work with you on this.

Thanks,
Vidhi