[tsvwg] Re: Comments from reading draft-ietf-tsvwg-l4sops-06

[Greg White <[e-mail]>]

Gorry,

Thanks very much for your review.  

For Issue 1, is anyone aware of security issues that are related to the material in this Informational draft?  If not, I can fill that in with some boilerplate text.
For Issue 2, I don't have specific plans for text.  That TODO was added in response to an earlier review comment, but if we don't have text I can delete it. 

Was there an Issue 3?

I've made all the editorial changes below (see one comment [GW]).

-Greg



On 3/3/25, 6:42 PM, "Gorry Fairhurst" <[e-mail] <mailto:[e-mail]>> wrote:


While reviewing drafts in the Transport Area Working Group Drafts, I 
volunteer some comments (as an individual) on the draft: 
draft-ietf-tsvwg-l4sops-06


Operational Guidance on Coexistence with Classic ECN during L4S Deployment


I note three significant issues to completing this work.


Issue 1:
The Security Consideration section is empty.


Issue 2:
TODO: more info on ways to cache/maintain such a list
- Do you have plans to add text here? or need help?


I also have some editorial issues for the next revision:
----


Abstract: Could we be bolder, if this has IETF consensus:
OLD:
This document is intended to provide guidance in order to ensure
successful deployment of Low Latency Low Loss Scalable throughput
(L4S) in the Internet.
NEW:
This document provided guidance to ensure
successful deployment of Low Latency Low Loss Scalable throughput
(L4S) in the Internet.
---
OLD:
over a Classic ECN bottleneck link.
NEW:
over a Classic ECN bottleneck.
- can we omit link? or change link to queue?
---
OLD:
This includes paths where the bottleneck link
NEW:
This includes paths where the bottleneck
- can we omit link? or change link to queue?
----
OLD:
RFC3168 has been updated (via [RFC8311]) to
reserve ECT(1) for experimental use only (also see [IANA-ECN]), and
its use for L4S has been specified in [RFC9331].
NEW:
RFC3168 has been updated (via [RFC8311]) to
reserve ECT(1) (also see [IANA-ECN]), and
its use for L4S has been specified in [RFC9331].
- I prefer the shorter form here if possible.
---
OLD:
The lower the capacity per flow,
NEW:
The lower the bandwidth delay product of a flow,
- Is this only the capacity of really the BDP?
---
OLD:
sharing a queue in a bottleneck link.
- is that the same meaning as sharing a bottleneck queue?
---
OLD:
The traditional norm for congestion response
- Some will quibble whether the word “traditional” is acceptable use, 
but I wonder whether the word could be omitted in this case?
---
OLD:
that eliminates RTT bias as much as possible
- might think this opens a debate, whereas “seek to mitigate” is 
certainly true?

[GW] this is a reference to requirement 4 in RFC9331 (https://www.rfc-editor.org/rfc/rfc9331.html#l4sid_Prague_req-rtt-independence) which reads "...a Scalable congestion control MUST converge towards a rate that is as independent of RTT as is possible without compromising stability or utilization".  The statement in L4Sops begins with "The L4S architecture aims to ..."  so it already isn't claiming that the aim is achieved.  But, perhaps it would be better if the text in L4Sops was a direct quote from RFC9331.  I'll change this to:

The L4S architecture aims to significantly improve this situation by requiring senders to adopt a congestion response that converges "towards a rate that is as independent of RTT as is possible without compromising stability or utilization" (see [RFC9331]).


---
OLD:
when a new flow joins an existing flow on a link
NEW:
when a new flow joins an existing flow sharing a bottleneck queue
- is this the same?
---
OLD:
So, in real networks, where per-application, per-end-host or per-
customer fairness may be more important than long-term, same-RTT,
per-flow fairness, it may not be that instructive to focus on the
latter as being a necessary end goal
NEW:
So, in real networks, where per-application, per-end-host or per-
customer fairness might be more important than long-term, same-RTT,
per-flow fairness, it might not be helpful to focus on the
latter as being a necessary end goal
---
OLD:
5.1.1. General purpose servers (e.g. web servers)
Out-of-band active testing could be performed by the server. For
example, a JavaScript application could run simultaneous downloads
(i.e. with and without L4S) during page reading time in order to
survey for presence of RFC3168 FIFO bottlenecks on paths to users
(e.g. as described in Section 4 of [Briscoe]).
In-band testing could be built in to the transport protocol
implementation at the sender in order to perform detection (see
Section 5 of [Briscoe], though note that this mechanism does not
differentiate between FIFO and FQ).
Depending on the details of the L4S congestion control
implementation, taking action based on the detection of RFC3168
FIFO bottlenecks may not be needed for short transactional
transfers that are unlikely to achieve the steady-state conditions
where unfairness is likely to occur
- The sense of this did not seem to match the other bullets in this list.
---
Section 8.2
OLD:
If the L4S experiment is deemed unsuccessful due to lack of
deployment of compliant end-systems or AQMs,
NEW:
If the L4S experiment is deemed unsuccessful (e.g., due to lack of
deployment of compliant end-systems or AQMs),
- This is only one reason why this might be unsuccessful. Although I 
certainly do note expect to see an evaluation of all reasons that could 
cause the EXP to fail.
---
Some RFCs are marked as Internet Drafts, the references ought to be 
updated to replace these by IETF RFC citations.
---
It would be good to separate normative and informative references:


I suggest the following are normative:
[RFC3168]
[RFC8311]
[RFC9330]
RFC9331]
[RFC9332]
----
Generally people prefer /e.g./e,g.,/