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 Briscoe http://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 Briscoe http://bobbriscoe.net/
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
