[tsvwg] Updated review: start of WGLC on L4S drafts: L4S Arch

[Gorry Fairhurst <[e-mail]>]

Adding to my own review, after re-reading L4S ID  ...

Gorry

On 12/08/2021 10:44, Gorry Fairhurst wrote:
> 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.
> ---

 >>>

I have now completed a review of L4S ID, I’ve now also reviewed “1.1.  
Latency, Loss and Scaling Problems” and I saw a much more polished 
version of the text with respect to DiffServ. To avoid doubt, here is 
the text I saw in L4S ID::

    The Diffserv architecture provides Expedited Forwarding [RFC3246], so
    that low latency traffic can jump the queue of other traffic. If
    growth in high-throughput latency-sensitive applications continues,
    periods with solely latency-sensitive traffic will become
    increasingly common on links where traffic aggregation is low. For
    instance, on the access links dedicated to individual sites (homes,
    small enterprises or mobile devices).  These links also tend to
    become the path bottleneck under load.  During these periods, if all
    the traffic were marked for the same treatment at these bottlenecks,
    Diffserv would make no difference.  Instead, it becomes imperative to
    remove the underlying causes of any unnecessary delay.
....

    Active queue management (AQM) was originally developed to solve this
    problem (and others).  Unlike Diffserv, which gives low latency to
    some traffic at the expense of others, AQM controls latency for _all_
    traffic in a class.

The above in the L4S-ID seems to me to be an acceptable presentation of 
the diffserv analysis and I did not find issues with this text, and 
other mentions in L4S-ID.

I wonder why the arch and L4S-ID both present this argument, ... and if 
we really do need two sets explaining diffserv inb both documents?

If this is really needed to be in both specs, could we just use the same 
words and avoid different flavours of discussion arising from the L4S 
ARCH document?

 >>>

> 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.
>
>