Re: [tcpm] New rev ready for WGLC: draft-ietf-tcpm-generalized-ecn-15

[Bob Briscoe <[e-mail]>]

Mirja,

Thank you for reviewing this promptly. Pls see [BB]...

On 15/12/2023 10:01, Mirja Kuehlewind wrote:
>
> Hi Bob, hi Marcelo, hi all,
>
> I reviewed this latest version of the draft. First, thanks for all the 
> work and this very well written document! This is important work for 
> both AccECN and L4S and I think the draft is absolutely ready for 
> working group last call.
>
> I only have one comment on Section3.3.2:
>
> This section says that for RFC3168 SYNs one needs to watch three or 
> four packets before disabling use of ECT. However, if all packets are 
> overwritten by the network with ECT, you might never detect that. 
> Further there is no way to tell that the other end [is not sending 
> non-zero ECN?] after the handshake negotiation.
>

[BB] I think there are some words missing from your sentence. I've added 
what I think you meant in [brackets].

Here's the offending sentence in the draft:
     "for RFC 3168 SYNs it needs to watch for three or four packets all 
set to CE at the start of a flow".
I think you've identified either an unclear sentence or some other 
weirdness here. See below.
>
> Therefore I still think it is fine and the only option to not 
> negotiate classic ECN support if a ECT/CE marked SYN is received. This 
> does not impact ECN++ because all [ECN-capable?] SYNs need to 
> negotiate AccECN. And as recently discussed (also basically in section 
> 5.3) it maybe even be desirable to not use (classic) ECN if AccECN is 
> not available on the server.
>

[BB] Again I've added a possibly missing word to your sentence using 
[brackets].

Disabling ECN for the connection if an ECN-capable RFC3168 SYN is 
received is one possibility (it's what Linux does if the first 4 
reserved flags in the TCP header are zero). However, as ECN host 
deployments proceed, altho' we still have to watch for bleaching to 
zero, I think the need to watch for mangling in the other direction 
(from zero to non-zero) is receding, which is why the draft says the 
following normative bullets:

        o  Any TCP server implementation SHOULD accept receipt of a valid SYN
           that requests ECN support for the connection, irrespective of the
           IP/ECN field of the SYN. ...
        o  A TCP implementation taking part in the ECN++ experiment MUST
           accept receipt of a valid SYN, irrespective of its IP/ECN field.


Don't forget that (at Michael Scharf's suggestion), an ECN-capable SYN 
is allowed on a SYN requesting AccECN "or an equivalent safety 
mechanism". And §3.2.1.1.2 
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-15#section-3.2.1.1.2> 
gives a couple of examples (IW1 or some future protocol beyond AccECN).

So, I hope you (and the WG) are comfortable with the second bullet 
quoted above, which mandates that a server taking part in the ECN++ 
experiment MUST accept an incoming ECN-capable SYN, even if the SYN is 
requesting an RFC 3168 connection.

[BB] Now, back to that weird "...three or four packets all set to CE". I 
think it might have been a weak/unclear attempt at a half-way house for 
incoming ECN-capable RFC3168 SYNs, between immediately disabling ECN and 
requiring more proof of mangling. Whatever, I think we should just 
delete this, 'cos it is not the job of the ECN++ draft to invent new 
mangling detection techniques for RFC3168 ECN, and the receiver isn't 
the best place to do it anyway. ECN++ is primarily about a packet sender 
setting the IP-ECN field. The only behaviour of a packet receiver that 
is in scope is whether it accepts the ECN-capable control packets sent 
by an ECN++ sender.

It's better for a packet *sender* to do any detection of mangling, by 
comparing the IP-ECN field it sent with feedback it receives (as AccECN 
does during the handshake, and AccECN suggests that the *sender* 
continues to watch for continuous CE feedback after the handshake.  
However, an incoming RFC3168 SYN indicates that the sender can't detect 
mangling of the SYN. So we could make it a SHOULD for an RFC3168 SYN, 
and a MUST otherwise.

I would prefer to leave it as it is (solely MUST), 'cos I think the time 
is right to declare the end of this particular network pathology, but I 
won't fight if the WG disagrees. Thoughts?

> Further I have some minor editorial issues(and one tiny nit I found…):
>
> 1) In Table 1: This is the only place where “Re-XMT” is used. This 
> seems a rather untypical abbreviation for me. I think I usually saw 
> RXT or something…
>

[BB] Tx and Rx are used for transmit and receive (from the days of the 
telegraph when it was more efficient to use a letter than '.' to 
represent abbreviation). [Stack Exchange 
<https://english.stackexchange.com/a/598501/334027>]
xmt and rcv are also used, because x is often used for trans, which is 
Latin for cross or across. [Stack Exchange 
<https://english.stackexchange.com/questions/200356/why-can-trans-be-replaced-with-an-x>]
But I've never seen RXT. Perhaps RTX? But I've just searched for "RXT 
abbreviation", "RTX abbreviation" and "ReTx abbreviation"; none seem to 
be used for retransmit. I also searched for "Abbreviation for 
retransmit", but nothing came up.

We have to use some form of abbreviation to minimize the table width. If 
no-one's got a more authoritative suggestion, I'll leave it as it is.

> 2) In section 4.9: “MORE MEASUREMENTS NEEDED (?):” -> Is this “(?)” 
> here still needed? What does it really mean?
>

As the text says, "If ... evidence ... , measurements would be needed". 
I'll write '(?)' in full as
     "POTENTIALLY MORE MEASUREMENTS NEEDED"

> 3) Section 5.1 on IW10 only say “Experimentation will be needed to 
> determine the best strategy.” -> Wasit on purpose that not same 
> highlighting style is used as for other described experiments?
>

[BB] This one has just had the tag overlooked. I'll add EXPERIMENTATION 
NEEDED, which is more appropriate here than MEASUREMENT NEEDED (as 
explained in §1.2 "Experiment Goals").

> 4) Section 5.4: “Building on the arguments in the current draft, a 
> QUIC sender sets ECT on all packets unless it fails the test for path 
> support.” I don’t think the arguments of this draft actually apply to 
> QUIC because QUIC doesn’t really have any “pure” control packets.
>

[BB] That's not quite the case. QUIC control frames might not be alone 
in a packet, but they can be. Nonetheless, I admit that I don't know 
whether anyone even considered making such packets not ECN-capable. We 
can just remove "Building on the arguments in the current draft,"

> NitSection 3.3.1: “Therefore, In order” -> “Therefore, in order” (lower i)
>

[BB] OK.

[BB] Thank you again for the review.

Given WGLC is imminent, we'll hold back from posting a new rev so we can 
fold in any other changes due to other people's comments (unless the 
chairs prefer otherwise).



Bob

> Thanks,
>
> Mirja
>
> *From: *tcpm <[e-mail]> on behalf of Bob Briscoe 
> <ietf=[e-mail]>
> *Date: *Saturday, 2. December 2023 at 22:27
> *To: *"[e-mail]" <[e-mail]>, Michael Tuexen 
> <[e-mail]>
> *Subject: *[tcpm] New rev ready for WGLC: 
> draft-ietf-tcpm-generalized-ecn-15
>
> Michael (as doc shepherd and co-chair), and tcpm,
>
> We've just posted a new rev of *ECN++*, which is now ready for WGLC.
>
> These changes to ECN++ require no further changes to the *AccECN* 
> draft, which stands as it was at draft-28 on 17 Nov.
>
>
>         Details
>
> Links to diffs are below, but here's a summary; just 3 changes:
>
> 1.Alternatives to the additional DupACK check for the case when SACK 
> blocks are being stripped.
>
> 2.Removed the description of how the latest sctpecn draft handles 
> control packets, as you (Michael) requested, given it is only interim.
>
> 3.Fixed a few URLs.
>
>
> NealC and RIchardS have suggested useful material, for which thanks.
> The alternatives to the DupACK check were compromises to (imperfectly) 
> address Markku's concern.
> I had hoped he would confirm whether they are acceptable. But instead 
> he has started digging a different hole (which I've just pointed out 
> is a rabbit hole to nowhere - see the list).
>
> So we've decided to post the ECN++ draft and request WGLC, which gives 
> Markku more time to respond.
>
>
>
> Bob
>
> On 02/12/2023 20:29, [e-mail] wrote:
>
>     Internet-Draft draft-ietf-tcpm-generalized-ecn-15.txt is now available. It is
>
>     a work item of the TCP Maintenance and Minor Extensions (TCPM) WG of the IETF.
>
>         Title:   ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets
>
>         Authors: Marcelo Bagnulo
>
>                  Bob Briscoe
>
>         Name:    draft-ietf-tcpm-generalized-ecn-15.txt
>
>         Pages:   51
>
>         Dates:   2023-12-02
>
>     Abstract:
>
>         This document specifies an experimental modification to ECN when used
>
>         with TCP.  It allows the use of ECN in the IP header of the following
>
>         TCP packets: SYNs, SYN/ACKs, pure ACKs, Window probes, FINs, RSTs and
>
>         retransmissions.  This specification obsoletes RFC5562, which
>
>         described a different way to use ECN on SYN/ACKs alone.
>
>     The IETF datatracker status page for this Internet-Draft is:
>
>     https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/
>
>     There is also an HTML version available at:
>
>     https://www.ietf.org/archive/id/draft-ietf-tcpm-generalized-ecn-15.html
>
>     A diff from the previous version is available at:
>
>     https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-generalized-ecn-15
>
>     Internet-Drafts are also available by rsync at:
>
>     rsync.ietf.org::internet-drafts
>
>     _______________________________________________
>
>     tcpm mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/tcpm
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/  <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-60c0becec43f4914&q=1&e=705c3752-7ce9-4aaa-9e8f-678e39aa197b&u=http%3A%2F%2Fbobbriscoe.net%2F>

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