Re: [tsvwg] start of WGLC on L4S drafts: draft-ietf-tsvwg-ecn-l4s-id, GF Editorial comments in WGLC

[Bob Briscoe <[e-mail]>]

Gorry,

Thanks for picking up this editorial points.
Assume they are accepted unless there's a [BB] comment inline...

Note that there's one that I've highlighted as a normative change, not 
just a nit.

On 13/08/2021 12:11, Gorry Fairhurst wrote:
> I have reviewed draft-ietf-tsvwg-ecn-l4s-id-19 in WGLC and have some 
> comments that I expect are editorial.
>
> (I seperately sent a couple of WGLC issues concerning this draft.)
>
> Best wishes,
>
> Gorry
>
> (as individual)
> ---
> NiT: Terminology could be cross-referenced.
> - I’ve just tried to compare the difference between the terminology in 
> L4S arch and L4S ID, and I found them to be identical, with the 
> exception that L4S arch also defines “site”.
>
> So:
> (a) Could we add “site” also as a definition to L4S-ID, the term is 
> also used in this ID.
> (b) Could you consider adding a one line statement to L4S arch that 
> says the two sets of definitions are identical, so that a reader 
> doesn’t need to check them when they read each document. I expect that 
> L4S-ID as an EXP Spec provides the normative text.

[BB] Good idea (I just posted l4s-arch, but I've added this to the 
editor's copy). And I've put an x-ref in both. As you suggest, I've said 
ecn-l4s-id the master, in case of any accidental differences.

> ---
> NIT: In Sect 1.1:
> - Can you expand FQ or provide a reference?
> ----
> NIT: I think this:
> “in the IP headers even in
>       one direction of a TCP connection will imply that both ends must
>       be supporting accurate ECN feedback.”
> ... Could perhaps be clearer as:
>      “in the IP headers even in
>       one direction of a TCP connection will imply that both ends
>       support accurate ECN feedback.”
> ---
> NIT: I think this:
> “in which AQMs filter out
>    variations before signalling congestion.”
> ... Could perhaps be clearer as (removing “out”):
> “in which an AQM filters
>    variations (i.e. smooths over time) before signalling congestion.”
> ---
> NiT:
> In 5.4.1.1. : “In a typical case for”... followed by “In this case it”.
> - To me these seem like the same case, should therefore these both be 
> in one single paragraph, rather than two?
> ---
> NiT:
> “ To include additional traffic with L4S, a network element only reads
>    identifiers such as those itemized above.  It MUST NOT alter these
>    non-ECN identifiers, so that they survive for any potential use later
>    on the network path.”
>
> - Actually I think this MUST statemen t only applies to the L4S 
> processing within the device, and I think it doesn’t mean L4S is 
> unable to work across a policy enforcement point or some other device 
> that otherwise modifies the other packet headers.
>
> .... so is this better as:
>
> “ To include additional traffic with L4S, a network element only reads
>    identifiers such as those itemized above.  The L4S forwarding
>   MUST NOT alter these
>    non-ECN identifiers, so that they survive for any potential use later
>    on the network path.”

[BB] Note that this is not a nit - it is a correction to a normative 
statement.
Also, there is no definition of what the extent of an 'L4S forwarding 
[element]' is. Classification for L4S might be much earlier in the path. 
How about

"The process of including additional traffic with L4S only involves 
reading identifiers such as those itemized above. It MUST NOT alter 
these non-ECN identifiers, so that they survive for any potential use 
later on the network path."

This is actually rather meaningless, because if a network element wants 
to alter any of the identifiers, it doesn't have to be part of "the 
process of including additional traffic with L4S". So the other 
alternative would be to remove any normative text from this para, and 
just say "The process ... wouldn't normally be expected to alter these 
identifiers." But I've left it with the MUST NOT, so as not to radically 
alter the draft.

> ----
> NiT: To avoid future discussion of whether this is ever used in other 
> cases, it might be better not to assert the deployment extent
> “But they cannot
>    easily satisfy this loss recovery requirement.  However, it is
>    believed they do not need to, because such implementations are
>    believed to solely exist in controlled environments, where the
>    network technology keeps reordering extremely low anyway.”
>
> .... so is this better as:
>
> “But they cannot
>    easily satisfy this loss recovery requirement.  When such 
> implementations are
>    used in controlled environments, the network technology can keep 
> reordering extremely low.”

[BB] This loses the originally intended sense about "not needing to". 
I'd rather just leave it as it is, because the requirement to do loss 
recovery in time units is now only a SHOULD anyway. So it's not only 
controlled environments where exceptions are allowed.


>
> ---
>
> NiT: Would it be OK to tweak this a little?
> “Setting ECT in Control Packets and Retransmissions
>
>    Description: This item concerns TCP and its derivatives (e.g. SCTP)
>    as well as RTP/RTCP [RFC6679].  The original specification of ECN for
>    TCP precluded the use of ECN on control packets and retransmissions.
>    To improve performance, scalable transport protocols ought to enable
>    ECN at the IP layer in TCP control packets (SYN, SYN-ACK, pure ACKs,
>    etc.) and in retransmitted packets.  The same is true for derivatives
>    of TCP, e.g. SCTP.”
> ... I think this might be better related to transports in general, and 
> rephrase the SCTP text - there is no IETF spec for ECN in SCTP (yet). 
> I suggest something like:
> “Setting ECT in Control Packets and Retransmissions
>
>    Description: This item concerns TCP and other transport protocols 
> (e.g. SCTP)
>    as well as RTP/RTCP [RFC6679].  The original specification of ECN for
>    TCP precluded the use of ECN on control packets and retransmissions.
>    To improve performance, scalable transport protocols ought to enable
>    ECN at the IP layer in TCP control packets (SYN, SYN-ACK, pure ACKs,
>    etc.) and in retransmitted packets.  The same is true for other
>
>    transports, e.g. QUIC, SCTP.
>

[BB] I'm happy to say 'other transports' instead of 'derivatives of 
TCP', but I'd rather not include QUIC in the list of examples, because 
that could imply that QUIC needs to be changed, when it doesn't.

Instead, I've added RTCP to the list, and moved the sentence about RTCP 
have a similar problem to the earlier problem part of the paragraph. As 
follows:

Description: This item concerns TCP and its derivatives (e.g. SCTP) as 
well as RTP/RTCP [RFC6679]. The original specification of ECN for TCP 
precluded the use of ECN on control packets and retransmissions. 
Similarly [RFC6679] precludes the use of ECT on RTCP datagrams, in case 
the path changes after it has been checked for ECN traversal. To improve 
performance, scalable transport protocols ought to enable ECN at the IP 
layer in TCP control packets (SYN, SYN-ACK, pure ACKs, etc.) and in 
retransmitted packets. The same is true for other transports, e.g. SCTP, 
RTCP.


> ----
>
> NiT: - Add Reference?
> “TCP Cubic was
>    designed to solve this problem”
> - please site the TCPM work item: draft-ietf-tcpm-rfc8312bis-03

[BB] I've cited RFC8312 many times in this draft already, so I'd prefer 
to just repeat that. if the 'bis' get to through RFC-editor first we can 
change it, but this sentence is about what Cubic has always done right 
from the start.

Thank you yet again, for you usual careful review. Next I'll address 
your technical points on ecn-l4s-id.

Cheers



Bob



>
> =====
>
>
>> -----
>>
>> On 29.07.21, 18:18, "tsvwg on behalf of Wesley 
>> Eddy"<[e-mail] on behalf of [e-mail]>  wrote:
>>
>>     This message is starting a combined working group last call on 3 
>> of the
>>     L4S drafts:
>>
>>     - 
>> Architecture:https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/
>>
>>     - DualQ:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/
>>
>>     - ECN 
>> ID:https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/
>>
>>     The WGLC will last through 4 weeks from today, and then we'll see 
>> what
>>     to do next.  Please submit any comments you have on these to the 
>> TSVWG
>>     list in that timeframe.
>>
>>     The chairs are considering a possible virtual interim following the
>>     close in order to work through feedback received.
>>
>>     The work on the L4S operational guidance draft is continuing in
>>     parallel, but that draft is not being last called yet.
>>
>>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/