Re: [tsvwg] Artart last call review of draft-ietf-tsvwg-l4s-arch-18

Marco,

Thank you for taking the time to review the whole document with fresh 
eyes - much appreciated.
We've taken all your points. In a couple of places, we modified a little 
- see [BB] inline.


On 20/07/2022 17:50, Marco Tiloca via Datatracker wrote:
> Reviewer: Marco Tiloca
> Review result: Ready with Nits
>
> Thanks for this document! Please see my comments below.
>
> Best,
> /Marco
>
> [General]
>
> * Based on the guidelines from RFC 7322, the "Acknowledgements" section should
> be unnumbered and placed between the "References" section and the "Authors'
> Addresses" section.
>
> * It is worth mentioning upfront that "capacity" refers to "link capacity" in
> terms of experienced bit rate. This becomes explicit only in Section 5.1, when
> discussing "Scalable throughput."

[BB] This is useful feedback.

We've substituted /capacity/link capacity/.

Because we in the transport area 'capacity' every day. So, to better 
understand the comprehension problem, can I ask what you thought 
'capacity' meant otherwise?
Do you want capacity explained in the terminology list?

> [Abstract]
>
> * The three components of the L4S architecture include "protocol features that
> allow network elements to identify L4S traffic".
>
>     The protocol in question becomes evident in Section 2 as ECN. The abstract
>     can already mention that, e.g., as "features of the Explicit Congestion
>     Notification (ECN) protocol that allow ..."

[BB] I've done this differently, 'cos I can see your point that many 
folks will just want to know what this protocol is, but shoe-horning it 
into this sentence adds distraction to what was meant to be a quick 
1,2,3. So, I propose to add the last sentence below. It makes the 
already-slightly-long abstract slightly longer, but...:

    The L4S architecture consists of three components: network support
    to isolate L4S traffic from classic traffic; protocol features that
    allow network elements to identify L4S traffic; and host support for
    L4S congestion controls. *The protocol is defined separately as an
    experimental change to Explicit Congestion Notification (ECN).*


>
> [Section 1]
>
> * "With some transport protocols, namely TCP and SCTP, the sender has to check
> for suitably updated receiver feedback, whereas with more recent transport
> protocols such as QUIC and DCCP, all receivers have always been suitable."
>
>     The first part of the sentence focuses on checking feedback from receivers,
>     while the second one on the actual receivers. Does the second part actually
>     mean "... feedback from all receivers is always suitable" ?

[BB] There's a zero-RTT handshake negotiation with the receiver, so one 
could say that the sender doesn't actually check the feedback, it checks 
what feedback the receiver says it supports. But the handshake is 
encoded into the feedback, so it's hard to draw a line between receiver 
and feedback. Whatever, how about this (I've changed yours to the past 
imperfect):

    With some transport protocols, namely TCP and SCTP, the sender has to check
    for suitably updated receiver feedback, whereas with more recent transport
    protocols such as QUIC and DCCP,*feedback from*  receivers*has*  always been suitable.


>
> [Section 2]
>
> * "... as the protocol to identify to the network which packets are L4S and
> which are Classic."
>
>     This should be something like "... as the protocol that allows the network
>     to identify which packets are L4S and which are Classic."

[BB] Yup

>
> [Section 5.2]
>
> * "... as opposed to TLS over UDP"
>
>     Do you mean "TLS over TCP" or rather "DTLS over UDP"? Or instead the use of
>     TLS for securing UDP-based transports such as QUIC?

[BB] DTLS

> [Nits]
>
> * Section 3: s/low enough not build/low enough to not build
>
> * Section 4.3: s/specifies that requirements that/specifies the requirements
> that
>
> * Section 5.1: s/because it assume/because it assumes

[BB] Got all these.

Thank you.



Bob

>
>


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

_______________________________________________
art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/art