Re: [tsvwg] Éric Vyncke's No Objection on draft-ietf-tsvwg-l4s-arch-19: (with COMMENT)

[Bob Briscoe <[e-mail]>]

Eric,

Thank you for taking the time to do a full review and comments.
Pls see a diff that includes the edits against your comments (and some 
for other people that crept in):
https://bobbriscoe.net/tmp/draft-ietf-tsvwg-l4s-arch-20c-DIFF-19.html

Also see [BB] inline for explanations and push-back on some:


On 24/08/2022 20:20, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-tsvwg-l4s-arch-19: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-tsvwg-l4s-arch-19
> CC @evyncke
>
> Thank you for the work put into this document. Please note that I am far from
> being an expert on transport issues... so I am afraid that my review is not
> deep and may have missed obvious points.
>
>   I especially like the incremental deployment approach.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
>
> Special thanks to Wesley Eddy for the shepherd's detailed write-up *including*
> the rough (?) WG consensus *and* the justification of the intended status.
>
> Please note that Benno Overeinder is the Internet directorate reviewer (at my
> request) and you may want to consider this int-dir reviews as well when Benno
> will complete the review (no need to wait for it though):
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/reviewrequest/16167/
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## COMMENTS
>
> ### id-nits and obsolete references
>
> [id-nits]
> (https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tsvwg-l4s-arch-19.txt)
> indicates two references to obsolete RFC (4960 and 7540). Probably worth
> updating the references.

[BB] Have done for 7540-> 9113
But I've mention that the x-ref to 4960 is intended, despite being 
obsolete, cos that's where the appendix outlining how ECN would be added 
to SCTP was (removed in 9260 that obsoletes it).

> ### Multicast ?
>
> While the answer seems obvious, should there be a mention that L4S technique
> only applies to unicast traffic ?

Multicast and anycast are addressed (very briefly) in the 'Scope' 
section of the EXP spec of the L4S ECN protocol.
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-28#section-1.3

L4S ECN is just as applicable with multicast as Classic [RFC3168] ECN, 
especially for unreliable multicast. For reliable multicast, there are 
the obvious scaling problems with feedback, but it's not untenable for 
small groups.

There's no architectural differences between multicast ECN and multicast 
L4S ECN to warrant saying anything in the L4S architecture. I think that 
sentence in ecn-l4s-id is sufficient. The original ECN spec [RFC3168] 
(that L4S ECN builds on) says that developing additional transport 
layers for unicast and multicast is for further study, and that's still 
the case.


[BTW, I was the one who pointed out that the original ECN draft (that 
became RFC3168) didn't mention multicast. And I posted this draft during 
the WGLC in 2001 that suggested a cool way of multicasting ECN (but 
probably impractical to implement):
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-ip-00#section-6

Actually, I'd be interested in your opinion of whether the scheme for 
suppressing all-but-one congestion marking during multicast forwarding 
would be any more feasible to implement today than it was then.
If you're interested, Figure 3 in the tech report that the above draft 
was derived from helps you quickly grock this multicast forwarding of 
only one ECN marking:
https://bobbriscoe.net/projects/2020comms/ecn/protocol/ip/ecnip_tr.pdf
]

> ###
>
> ### Very long abstract...
>
> This is probably the longest abstract for the last couple of months ;-)
>
> No need to reply or change the document, but the abstract also somehow smells
> like a marketing text...

[BB] Length has already been dealt with, following similar comment(s).
https://bobbriscoe.net/tmp/draft-ietf-tsvwg-l4s-arch-20a-DIFF-19.html

> ### Section 1, on purpose ?
>
> ```
>     ... Queuing in access
>     network bottlenecks is typically configured to cause overall network
>     delay to roughly double during a long-running flow, relative to
>     expected base (unloaded) path delay [BufferSize].
> ```
>
> Is this really configured so on purpose ? Probably not, even if the above text
> seems to indicate that this is on purpose.

[BB] I'm afraid it is on purpose. This is how TCP Reno has worked since 
1988. TCP's well-known halving on each drop implies that, at the top of 
each sawtooth, the buffer holds a base round trip's worth of queue 
delay, so total RTT oscillates between 1 & 2 base RTTs. That's the 
implication of one bandwidth-delay product of buffer.

BTW, that's tiny compared to the bloated buffers some operators 
configure (multiple seconds of buffer).
See the bufferbloat project, which has been evangelizing getting buffers 
down to this minimum of just one (additional) round trip's worth of 
buffer, preferably with an AQM too.
But state-of-the-art AQMs (pre-L4S) still have to accommodate TCP's 
large sawteeth in the buffer.

> ### Section 1, TCP only ?
>
> The following text seems to indicate that TCP is the major transport protocol,
> but (see caveat about my lack of transport expertise) it seems to me that QUIC
> (and plain UDP) are becoming more important: ```
>     The root of the problem is the presence of standard TCP congestion
>     control (Reno [RFC5681]) or compatible variants (e.g. TCP
>     Cubic [RFC8312]).
> ```
> I.e., if similar mechanisms exist in QUIC, then it is worth mentioning.

[BB] Reno is the default CC in QUIC. I've reworded:

    The root of the problem is the presence of standard congestion
    control (Reno [RFC5681]) or compatible variants (e.g. CUBIC
    [RFC8312]) that are used in TCP and in other transports such as
    QUIC [RFC9000].


See diff (link at the start) for this in context.

> ### Section 2, incremental deployment ?
>
> ```
>     ... Because ECN support is
>     essential for L4S, senders use the ECN field as the protocol that
>     allows the network to identify which packets are L4S and which are
>     Classic.
> ```
> seems to contradict the 'incremental deployment' statement as the network needs
> to be able to differentiate traffic. Or did I miss something ?

[BB] This is all explained in the following subsections on deployment: 
§6.4.3 
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch-19#section-6.4.3> 
& §6.4.4 after it.

> ### Section 2, which part of the host ?
>
> ```
>        ... A host needs to distinguish L4S and Classic packets
>        with an identifier so that the network can classify them into
>        their separate treatments. ...
> ```
> I would assume that a host stack as a local API so that applications can signal
> L4S vs. classic traffic.

[BB] Yup. That's one obvious way.

> Also, it is unclear (to me) whether it is the sending part of the host or the
> receiving part ?

[BB] s/host/sending host/
See diff for this in context.

> Finally, with some transport services (e.g., QUIC) moving to the user space, is
> the above statement still applicable ?

[BB] Definitely, yes.

And this is why the draft just says "the sending host", 'cos where in 
the stack it's sent from depends on the type of transport.
For instance:
* Google's L4S support within BBRv2 is in the kernel if over TCP (but 
BBRv2 is also implemented within QUIC).
* Apple's L4S congestion control in QUIC is in userland over UDP, which 
developers can now enable in MacOS and iOS to test their apps.
* NVIDIA has implemented L4S congestion control over raw UDP for 
testing, and so has Nokia, both for video transport
* Ericsson has implement L4S in their real-time media SCReAM congestion 
control over RTP/RTCP (over UDP of course)
* Meta is testing the Prague congestion control that we (the L4S design 
team) implemented as a reference for TCP in the Linux kernel

So you can see, there are nearly as many possibilities as initial 
implementations (the above were all brought to the first L4S interop in 
Philly at IETF-114).
See https://l4s.net/#code for links to most (always slightly out of date 
- it's fashionable).


> ### Section 4.1
>
> Unsure how `unassignment of an identifier` relates to item a) below.

[BB] It's in the last sentence of a):

        [RFC8311  <https://datatracker.ietf.org/doc/html/rfc8311>] also
        reclassifies the original experimental assignment of the ECT(1)
        codepoint as an ECN nonce [RFC3540  <https://datatracker.ietf.org/doc/html/rfc3540>] as historic.


Actually, I can see that sentence is hard to parse. See diff for a new 
attempt.


> ### Section 6.1
>
> Again, please bear with my lack of knowledge, but I wonder what is the 'load'
> in the text below. Is the 'load' only interactive traffic(then I wonder how there could be no congestion)  or is it a mix with non-interactive traffic (the
> proverbial SW upgrade,which can be delayed): ```
>     With the L4S approach, the following existing applications also
>     experience significantly better quality of experience under load:
> ```

[BB] Load means anything that is filling the pipe - it will include the 
application listed, which might alone be able to fill the pipe. But it 
could also include many applications running in parallel, perhaps a mix 
of those listed, or perhaps including your s/w download. Or ...

BTW, I've marked a couple of passages green in your text that make me 
think there's a misconception here somewhere.
An example might help: in this demo: 
https://riteproject.eu/dctth/#1511dispatchwg there were 4 large file 
downloads in parallel to the interactive video app. On the left, the 
video app _and_ all the downloads were using an L4S congestion control 
(all actually TCP Prague) so they all filled the pipe all the time. 
Nonetheless _all_ the packets (including those of the downloads) 
experienced very low queueing delay.

> ### Section 6.3
>
> This section could probably be extended as Wi-Fi & satellite links have
> properties going beyond latency (e.g., packet loss).

[BB] I've added a para as follows:

"Also certain link types, particularly radio-based links, are far more 
prone to transmission losses. Section 6.4.3 explains how L4S congestion 
controls have to respond as drastically to loss as the Classic controls. 
Nonetheless, research referred to in the same section has demonstrated 
potential for considerably more effective loss repair at the link layer, 
due to the relaxed ordering constraints of L4S packets."

For this in context, see diff.

> For a non native English reader, the use of 'pole' is really hard to parse.

[BB] As a Brit, I had never heard of the expression 'longest pole in the 
tent' (which apparently has fairly recent American origins). However, I 
adopted it, 'cos it painted a strong picture in my mind. So I'm 
surprised to hear it doesn't translate well. I'll leave it unless you 
really think this would be a bad move.

> ### Section 8.1 and others
>
> I wonder whether this section belongs to security considerations or rather to
> deployment considerations.

[BB] It is a common misconception in computing to think of security as 
just /information/ security. But isolation, starvation prevention, 
traffic policing etc, are all security-related functions.

> ### Section 8.4
>
> The text does not convince me that ECN can be trusted (i.e., the network
> provides ECN integrity). Should there simply be some text about 'best effort' ?

[BB] Drop cannot be trusted as a congestion signal either, because the 
sender doesn't have to respond to it. But Internet congestion control 
has depending on this untrustworthy signal for 34 years, and worked 
well. The interesting question is 'Why?' That might be where you are 
going with your comment about 'best effort'?

     Aside: This appendix about ECN integrity in l4s-arch currently 
gives a slightly briefer version of similar info in an appendix of 
ecn-l4s-id, and then refers to it.
     So, instead, we've decided to have the info in one place 
(ecn-l4s-id) and in l4s-arch just cross-refer to it along with a much 
briefer single-sentence summary of what it's about.

To your point (if I understand it correctly), I've added the following 
at the end:
"At the time of writing, It is not common to protect the integrity of 
congestion feedback, whether loss or Classic ECN. If this position 
changes during the L4S experiment, one or more of the above techniques 
might need to be developed and deployed."

Is that sthg like what you were looking for?

> ### Privacy considerations
>
> Does the use of visible ECN marking leak some information about its
> (potentially encrypted) content ?

[BB]
If you mean the ECN codepoint chosen by the sender:
     See §8.5 on Privacy Considerations, and conversation with Roman 
Danyliw on this point subsequent to his review:
https://mailarchive.ietf.org/arch/msg/tsvwg/pV0uW56svXtlA24fuLO14KgkPCM/
     In summary,
         draft says identifier for a very broad class helps people hide 
in the crowd from correlation analysis
         Roman wondered if early or late adopters would be more identifiable
         My response was, anyone who cares about privacy that much can 
choose not to stand out, sop avoid being either.
else, if you mean ECN congestion markings applied by the network
     Probably not (it might help identify the behaviour of the 
congestion control, which might )


> ## NITS
>
> ### E.g. comma
>
> AFAIK, all 'e.g.' must be followed by a comma.

[BB] That's American English style, which tends to have more commas 
generally.
I've written in British English style.
https://english.stackexchange.com/a/231071/334027
https://english.stackexchange.com/a/351762/334027

The RFC Editor will be the final arbiter of style. They ensure an RFC is 
consistently either one or the other, and have their own British English 
editors.

> ### Spec
>
> Suggest to use 'specification' rather than 'spec' ;-)

[BB] I checked this during writing. Apparently, like fridge, spec is now 
considered a word in its own right, and addition of a full-stop is 
deprecated.
https://chambers.co.uk/search/?query=spec&title=21st
https://www.merriam-webster.com/dictionary/spec

As I said, the edits for you are in this diff:
https://bobbriscoe.net/tmp/draft-ietf-tsvwg-l4s-arch-20c-DIFF-19.html


Thank again very much for your careful review.
I look forward to seeing any further responses you might have.



Bob


>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
>
> [ICMF]:https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]:https://github.com/mnot/ietf-comments
>
> *************
> As noted inhttps://www.ietf.org/blog/handling-iesg-ballot-positions/, a
> DISCUSS ballot is a request to have a discussion; I really think that the
> document would be improved with a change here, but can be convinced otherwise.
>
>
>


-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/