Re: [tsvwg] Éric Vyncke's No Objection on draft-ietf-tsvwg-ecn-l4s-id-28: (with COMMENT)

[Bob Briscoe <[e-mail]>]

Eric,

On 25/08/2022 14:09, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-tsvwg-ecn-l4s-id-28: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07
> CC @evyncke
>
> Thank you for the work put into this document. Like well-written by Paul
> Wouters in another review, I am not a TSV person...
>
> I also appreciate the experimental status with a description of the experiment
> itself.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
>
> Special thanks to Wesley Eddy for the shepherd's detailed write-up including
> the WG consensus **and** the justification of the intended status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## COMMENTS
>
> ### Update RFC 3168
>
> No need to comment, but it was very smart for the authors of RFC 8511 to allow
> such experiments ;-)
>
> There is some duplicate text in sections 1.3 and 2 on this though...

[BB] I'm going to leave both, 'cos the half-sentence in §2 is a much 
briefer summary.
If I remove it, I have a feeling I'll be asked to explain how an EXP can 
define an alternative to a PS.

>
> ### Section 1
>
> A lot of the content of this section appears to be identical or similar to the
> architecture draft. Consider removing some text ?

[BB] This has been discussed in the WG with some pro and some con, and 
this was the result.
The idea is that each doc contains sufficient background to be 
stand-alone, while anyone who has read one can skip/scan the 
introductory material in the other.

> ### BCP 14
>
> Please use the right template for BCP14 in section 1.2.

[BB] I'm going to do this systematically to all three drafts when I go 
through the machine-generated genart review from Lars (which also points 
this out).

> ### Section 5.4.1.1 unresponsive
>
> Is `unresponsive traffic` a well-defined term ?

[BB] Yes, very much so - certainly in the transport area. It has 
replaced the older imprecise term "UDP traffic", given a huge number of 
apps and transports now use congestion control over UDP.
And, indeed, the TCP Reno standard [RFC5681] allows TCP to become 
unresponsive below it's minimum window of 2 segments per RTT.

>
> ### Section 5.4.1.1 ARP, DNS
>
> In the example for low-level traffic, ARP, DNS, I am unsure whether ARP is
> really routed through an IP network ;-) or are Ethernet switches also covered
> by this I-D? You may also qualify 'DNS' into 'DNS queries'.

[BB] The bottleneck buffer, and therefore best location for an AQM, can 
be below the IP layer.
Certainly Ethernet switches are one good example. Indeed, the AQM for 
DCTCP is nearly always implemented on "L3 switches".
Another example: the RAN in mobile.

Why only DNS queries? Why not responses too?

>
> ### Section 6.2
>
> ```
>     ... If a mix of L4S and Classic packets is sent into the same security
>     association (SA) of a virtual private network (VPN), and if the VPN
>     egress is employing the optional anti-replay feature, ...
> ```
>
> Suggest to used IPsec in tunnel mode as they are many kinds of VPNs.

[BB] This introductory sentence was deliberately generic, 'cos the next 
sentence says

    This known problem is common to both IPsec [RFC4301  <https://datatracker.ietf.org/doc/html/rfc4301>] and
    DTLS [RFC6347  <https://datatracker.ietf.org/doc/html/rfc6347>] VPNs, given they use similar anti-replay window
    mechanisms.


[BB] In summary, I've found there are no changes.
I hope I've explained and justified all that alright.

Thank you anyway.

Regards



Bob


>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
>
> [ICMF]:https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]:https://github.com/mnot/ietf-comments
>
>
>

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