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

Marco,
OK. Thank you again. All items done.
Bob

On 24/07/2022 20:18, Marco Tiloca wrote:
> 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

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

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