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

Marco Tiloca <[email protected]> Sun, 24 Jul 2022 15:18:12 -0400
Newsgroups	gmane.ietf.apps-discuss,gmane.ietf.tsvwg
Message-ID	<[email protected]>
Hi Bob,

Thanks for your replies! Please see inline.

Best,
/Marco

On 2022-07-24 14:03, Bob Briscoe wrote:
> 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?

==>MT
Honestly, common sense does suggest "capacity" to be referred to 
experienced bit rate over the link.

But until I saw that confirmed in Section 5.1, I wondered: i) if 
"capacity" could (also) refer to, e.g., session establishment rate, 
maximum number of users/sessions that can be afforded etc. ; and ii) 
what "capacity" was applied to, i.e., a link, a network segment, a pool 
of network resources, etc.

I think that using "link capacity" should be good and clear enough now :-)
<==

> Do you want capacity explained in the terminology list?

==>MT
No; at least from my point of view, I don't see that as necessary.
<==

>
>> [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).*
>
>

==>MT
Looks good.
<==

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

==>MT
Looks good.
<==

>> [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/

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: +46 (0)70 60 46 501

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se

_______________________________________________
art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/art
OpenPGP_0xEE2664B40E58DA43.asc (application/pgp-keys, 4.5 KB)
OpenPGP_signature (application/pgp-signature, 495 B) - not displayed