Re: [tsvwg] start of WGLC on L4S drafts

[Gorry Fairhurst <[e-mail]>]

I reviewed Low Latency, Low Loss, Scalable Throughput (L4S) Internet 
Service Architecture during the WGLC. I support publication, but I think 
there are issues that would need to be addressed relating to the way L4S 
is presented.

Best wishes,

Gorry


This is a review of draft-ietf-tsvwg-l4s-arch-10:

1a) Issue: “It is increasingly common for _all_ of a user's applications 
at any
    one time to require low delay: interactive Web, Web services, voice,
    conversational video, interactive video, interactive remote presence,
    instant messaging, online gaming, remote desktop, cloud-based
    applications and video-assisted remote control of machinery and
    industrial processes. “
- I generally agree on the value for a wide range of applications and 
sect 6.1 appears to contain a helpful list. ~ However, I disagree that 
the word “all” is necessary or correct in this section. I think there 
are cases that do not fit. Background software update, retrieval of 
logging data, some cases where loss protection is more important than 
for other traffic, etc, So I insist there are examples that do not 
require this. I expect I could find more examples, but I’d prefer the 
word “all” to be removed, to leave this as a generalisation.
---
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?
---
2) NiT
“The L4S
    approach also requires component mechanisms at the endpoints to
    fulfill its goal.”
- True, can you provide examples of what these mechanisms are (or a 
cross ref)? e.g., are they Protocol Mechanisms (as they are called in 
section 4.1)? or is this more the  to Host Mechanisms (section 4.3) ?
---
3) Issue or reword.
“Although DCTCP as-is 'works' well over the public
       Internet, most implementations lack certain safety features that
       will be necessary once it is used outside controlled environments
       like data centres (see Section 6.4.3 and Appendix A).”
- If this is published by the iETF, then I think this needs to have 
consensus that DCTP is acceptable. I don’t now which RFC states that.
Later this ID states: “ DCTCP needs some safety concerns to be fixed for 
general use
    over the public Internet (see Section 4.3 of
    [I-D.ietf-tsvwg-ecn-l4s-id]),”
which seems much closer to what is needed in this section.
---
4) NiT
“With
       Classic congestion controls, such as Reno or Cubic, because flow
       rate has scaled since TCP congestion control was first designed in
       1988, it now takes hundreds of round trips (and growing) to
       recover after a congestion signal (whether a loss or an ECN mark)
       as shown in the examples in Section 5.1 and [RFC3649].
“
- This only seems like a correct statement, if the flow is a bulk / high 
volume flow that is using a high capacity path? Please check and clarify.
---
5) NiT
“such as QUIC.”
- Reference needed for [RFC9000].
---
6) NiT
“[I-D.ietf-tsvwg-ecn-l4s-id] recommends ECT(1)”
draft-ietf-tsvwg-ecn-l4s-id appears to “specify” the use of ECT(1) for 
this purpose. Please check whether ECT(1) is only recommended.
---
7) Issue: TCP is a core protocol, and L4S support depends on Accurate 
ECN: Is accurate ECN a normative?  (see comment 22)
“Work to standardize and implement more
           accurate ECN feedback for TCP (AccECN) is in
           progress [I-D.ietf-tcpm-accurate-ecn],”
---
8) NiT In section 2, ref useful:
“high level explanation of how FQ”
- Please expand and add reference for FQ.
---
9) Typo:
“ The 'Low Loss” part of the name denotes”
- This has mixed quote marks. In other places, double quotes are used.

---

10) Issues relating to critique of diffserv:

10a) Making assertions about Diffserv:
I really don’t like this choice of words, it’s far too general a conclusion:
“      Also, Diffserv only works for a small subset of the traffic on a
       link. “
- Diffserv  works fine when all traffic is marked with a set of DSCPs - 
I hope you’d agree, but there are cases where it wouldn’t give benefit, 
e.g. when all traffic on a congested link/router is marked with one code 
point, whereas there may be benefit if all traffic on a link/router is 
marked with one code point, when that traffic later shares bandwidth 
with traffic carrying other marks.
---
10b) Making assertions about Diffserv:
“As already explained, it is not applicable when all the
       applications in use at one time at a single site (home, small
       business or mobile device) require low latency.”
- See above. I really don’t like saying it is not applicable. It can be 
applied, and it can give benefit - I’d accept there was no benefit if 
the traffic was all marked the same and the resources were constrained 
in that part of the network.
---
10c) In security considerations, making assertions about Diffserv:
“Diffserv only works if some packets
    get less favourable treatment than others.”
- Again not so, the word “works” is problematic. Offers benefit is 
perhaps more true?
---
10d) In security considerations, making assertions about Diffserv:
“So Diffserv has to use
    traffic rate policers to limit how much traffic can be favoured.”
- I do not agree in this general conclusion and I think this was 
discussed in previous comments. This is not the place to make sweeping 
statements about diffserv, or how it might be used. I would strongly 
urge you to remove this sweeping statement.
---
10e) In security considerations, making assertions about Diffserv:
“In
    turn, traffic policers require traffic contracts between users and
    networks as well as pairwise between networks. “
- Does it actually need to be a contract with a user, I don’t thinks so, 
there are many cases where diffserv marks are applied in the network, or 
at an enterprise edge. This is not the document to make such statements 
about diffserv. I’m going to argue that you need to remove this phrase, 
people can decide to use L4S without having to address this.
---
11) Issue: Making assertions about Diffserv:
“   In particular, because networks tend not to trust end systems to
       identify which packets should be favoured over others, where
       networks assign packets to Diffserv classes they often use packet
       inspection of application flow identifiers or deeper inspection of
       application signatures.  Thus, nowadays, Diffserv doesn't always
       sit well with encryption of the layers above IP.  So users have to
       choose between privacy and QoS.
“
This might, or might not be true, but there are no RFCs or references 
sited, and I am unsure why this para is actually needed in an RFC: If it 
is, then it needs some specific discussio by the WG, but maybe it would 
be more prudent to not say this.

---
12) Issue: This seems not quite true:

“     A.  Per-flow forms of L4S like FQ-CoDel are incompatible with full
           end-to-end encryption of transport layer identifiers for
           privacy and confidentiality (e.g. IPSec or encrypted VPN
           tunnels), because they require packet inspection to access the
           end-to-end transport flow identifiers.
“
I am also unsure why this para is actually needed in this ID!

A network flow ID can be used with FQ, and I think should be noted. I 
also thought this seemed slightly misleading by not mentioning that TLS 
over UDP still exposes the port info needed to classify in FQ. I’s 
suggest removing this ... it seems a well known effect of 
classification/scheduling on traffic aggregates.
---
13) Ref
In reference to scavenger service, can you add a reference to an RFC as 
well as [LEDBAT_AQM]?
---
14) Query:
“ Indeed BBRv2 [BBRv2] uses L4S ECN...”
- Is this necessarily true that ECN is used, and the final spec for BBR2 
specifies this? Might it be fairer to say:
“ Indeed BBRv2 [BBRv2] can use L4S ECN...”
---
15) NiT: In 6.4.1:
“   L4S AQMs will not have to be deployed throughout the Internet before
    L4S will work for anyone.”
- Is this “work” for anyone? or “can benefit anyone”?
---
16) NiT:
“Deployment in mesh topologies depends on how over-booked the core is.”
- sentence ends in “is”... which seems strange. Is “over-booked” well 
understood or should this be “over-provisioned” perhaps?
I’d suggest something more like:
“Deployment in a mesh topology depends on how much the core is 
over-provisioned.”
---
17) NiT: In 6.4.2.:
    “For any one L4S flow to work, it requires 3 parts to have been
    deployed.”
- what does “work” mean here? is this offer benefit or is this 
dysfunctional in some way unless this happens or what?
---
18) NiT:
This seems wrong from a diffserv viewpoint:
“they are required not to change the L4S
    identifier, merely treating the traffic as best efforts traffic, as
    they already treat traffic with ECT(1) today.”
- e.g. could we change to something like :
“they are required not to change the L4S
    identifier, merely treating the traffic in the same way as not-ECT 
traffic, as
    they already treat traffic with ECT(1) today.”
---
19) NiT:
“to police L4S traffic in order to
    protect competing Classic ECN traffic.”
- Is policing in an order - if so explain, otherwise please rephrase to 
“to police L4S traffic to protect competing Classic ECN traffic”
---
20) NiT:
“Their packet classifier (item 2 in Figure 1) could identify
    such customers against some other field (e.g. source address range)
    as well as ECN.”
/ECN/as classifying on the ECN Field/.
---
21) NiT:
“The TCP authentication option (TCP-AO [RFC5925]) can be used to
       detect tampering with TCP congestion feedback.”
-It seems strange to not also mention that QUICs use of TLS also prevent 
this tampering.
---
22)Query:  I think some references could need to be normative:
RFC3168
RFC8311
I-D.ietf-tcpm-accurate-ecn

-----

On 29.07.21, 18:18, "tsvwg on behalf of Wesley Eddy"<[e-mail] on behalf of [e-mail]>  wrote:

     This message is starting a combined working group last call on 3 of the
     L4S drafts:

     - Architecture:https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/

     - DualQ:
     https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/

     - ECN ID:https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/

     The WGLC will last through 4 weeks from today, and then we'll see what
     to do next.  Please submit any comments you have on these to the TSVWG
     list in that timeframe.

     The chairs are considering a possible virtual interim following the
     close in order to work through feedback received.

     The work on the L4S operational guidance draft is continuing in
     parallel, but that draft is not being last called yet.