Re: Accurate ECN support in tcpdump/libpcap

["Scheffenegger, Richard via tcpdump-workers" <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: "Scheffenegger, Richard" <Richard.Scheffenegger () netapp com>
>
> Date: Tue, 5 Sep 2023 08:50:36 +0000
>
> Hi Francois-Xavier!
>
> > I think there's an ambiguity here.
>
> I respect your opinion on this; It would be nice to hear the opinions of more people using and improving tcpdump. 
> Currently it seems to me, that only you and I have particularly strong convictions about the abbreviation letter...
>
> > If you think this is a problem for the new flag, have you considered modifying the two tools you mention with two 
> > small patches?
>
> It's not the change in packetdrill by itself that I'm worried about, but all the deployed and productive regression 
> testing scripts already using the "A" (and 0..7) notation.
>
> At this stage it probably would be easier to sed "s/N/A/" on the tcpdump output when creating a new script from tcpdump 
> captures. My packetdrill scripts tend to use the "A" notation only during the handshake and then use the numerical 
> notation supported by packetdrill. But I know that many of the scripts in the Linux world don't make use of the 
> numerical notation for in-session header flags.
>
> Adding the maintainer of packetdrill and the author of the wireshark patch for their view on this.
>
> > Thus my proposal to use "N", last letter of "Accurate ECN", as already suggested in some PR comments and a previous 
> > message.
> > Mnemonic: "Accurate EC[N]" or "[N]ew TCP scheme/mechanism".
> > Alternatives:
> > - "M" from "[M]ore Accurate Explicit Congestion Notification", from your draft title.
> > - "G" from "TCP Pra[G]ue", perhaps less mnemonic.
>
> From these, I could accept the "N" for the historic precedent (Nonce Sum bit) and "Accurate EC[N]" if others support 
> that too. I maintain that "A" is most appealing to me, the other alternatives I'm not really fond of; BTW - TCP Prague 
> is more than just the AccECN signalling; you have changed IP ECN use (ECT(1) instead of ECT(0)), but most importantly, 
> the congestion control mechanisms is based around DCTCP, and Loss recovery is based upon RACK (as a typical starting 
> point)
>
>
> > s/for a couple months/for 2 years and half/ Your Proposal to packetdrill: Jan 18, 2020. Your PR to tcpdump: Jul 27, 
> > 2022.
> > Denis questions: Oct 23, 2022. No answer until Jul 23, 2023.
>
> Indeed. Technically, Jul 2022 to Jul 2023 is 12 months, which fits with couple of months. Prior to that, the tcpdump 
> project has had no formal knowledge...
>
> Originally (2020) I had not properly set up the git repository and was only reminded about this at the IETF114 
> hackathon.
> Denis email response to me was unfortunately earmarked as junk due to the long time difference of July 2022 to October 
> 2022 - I presume the filter wasn't expecting an answer after almost 3 months... I only unburied it during the IETF117 
> hackathon. And matters got delayed a bit more with the recent issues around this lists mailman.
>
>
> In order to make some progress, I suggest to split off the part of the patch, which allows access to all 12 TCP header 
> flags, and submit that separately; This could be committed together with the adjacent change to libpcap (the parser 
> decoding the literal "tcp[tcpflags]" string to provide also all 12 flag bits. Would that be agreeable?
>
>
>
> Richard Scheffenegger
>
> -----Original Message-----
> From: Francois-Xavier Le Bail <devel.fx.lebail () orange fr>
> Sent: Dienstag, 5. September 2023 09:35
> To: Scheffenegger, Richard <Richard.Scheffenegger () netapp com>; tcpdump-workers () lists tcpdump org
> Subject: Re: [tcpdump-workers] Re: Accurate ECN support in tcpdump/libpcap
>
> NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the 
> sender and know the content is safe.
>
>
>
>
> On 29/08/2023 16:34, Scheffenegger, Richard via tcpdump-workers wrote:
> > And some initial discussions which aren't yet reflected on the mailing list:
> >
> > -----Original Message-----
> > From: Scheffenegger, Richard
> > Sent: Freitag, 18. August 2023 14:01
> > To: Francois-Xavier Le Bail <devel.fx.lebail () orange fr>;
> > tcpdump-workers () lists tcpdump org
> > Cc: Denis Ovsienko <denis () ovsienko info>; Guy Harris
> > <gharris () sonic net>; [...] ; Michael Richardson <mcr () sandelman ca>;
> > [...]
> > Subject: RE: Accurate ECN support in tcpdump/libpcap
> >
> > (Adding everyone who has participated in the discussion so far, since
> > it seems that tcpdump-workers mailman is not working, as well as a
> > number of additional recent committers and participants)
>
> [...]
>
> > I do not think there is ambiguity here.
>
> Hi Richard,
>
> I think there's an ambiguity here.
> Using "A" as the new TCP flag for tcpdump is a mistake because it sounds like "ACK" (even if tcpdump prints "." for 
> "ACK").
> Thus my proposal to use "N", last letter of "Accurate ECN", as already suggested in some PR comments and a previous 
> message.
> Mnemonic: "Accurate EC[N]" or "[N]ew TCP scheme/mechanism".
> Alternatives:
> - "M" from "[M]ore Accurate Explicit Congestion Notification", from your draft title.
> - "G" from "TCP Pra[G]ue", perhaps less mnemonic.
>
> > Tcpdump - any every tool afterwards - has been using "." for ACKs.
>
> This is incorrect. Wireshark, for example, does not use "." for ACKs.
>
> > "N" had been in (very rare) use for the NS bit (RFC3540), which is now obsolete 
> > (https://datatracker.ietf.org/doc/status-change-ecn-signaling-with-nonces-to-historic/). While this is the same bit 
> > (and arguably, the authors of RFC3540 could have made more effort to get that bit adopted in tooling back in 
> > 2001-2003), the semantics are dramatically different than the current use.
> >
> > "A" has never been in use before, as a single character abbreviation,
>
> This is incorrect. Wireshark uses "A" for "ACK".
> (e.g. TCP Flags: ····C··A··S·)
> ------------------------^
>
> > and is in use for the last 2+ years in other tooling around packet mangling, tracing, decoding and forging such as 
> > wireshark and packetdrill...
> > (and yes, I did let the ball drop with tcpdump for a couple months, when all the other tools were updated reflecting 
> > the "A" char change there, which was completely uncontentious in those communities).
>
>
> > I suspect it would create more confusion, if tcpdump was using a
> > different mapping, than other tools
>
> There are already some different mapping between, for example, Wireshark and tcpdump:
> ACK: "." for tcpdump, "A" for Wireshark.
> CWR: "W" for tcpdump, "C" for Wireshark.
>
> If you think this is a problem for the new flag, have you considered modifying the two tools you mention with two small 
> patches?
>
> Wireshark, for example, prints "AE" without -V, e.g. "[SYN, ECE, CWR, AE]". No "A" alone here.
> And the only place where the new "A" appears is with -V:
> TCP Flags: ···ACE····S·
> --------------^
> It appears with:
>   "...1 .... .... = Accurate ECN: Set"
>
> If it's a problem, it could easily be changed to e.g. "N", with a little patch.
>
> Same for packetdrill.
>
> > (just like with the "." for Ack, which is in common use throughout those very same tools).
>
> And again « the "." for Ack » is not used by Wireshark, one of « those very same tools ».
>
> > Another interesting aspect which I would be keen on learning, if per-session stateful decoding is something that the 
> > tcpdump community would entertain. Once the AccECN handshake (in a SYN) was seen, subsequently the AE, ECE and CWR 
> > bits together form the ACE counter. In packetdrill and also wireshark this gets then decoded numerically (0..7) 
> > instead of having one character per bit...
>
> This per-session stateful session decoding could be examined later...
>
> > Best regards,
> >   Richard
>
> Best regards,
> François
>
> > -----Original Message-----
> > From: Francois-Xavier Le Bail <devel.fx.lebail () orange fr>
> > Sent: Freitag, 18. August 2023 13:20
> > To: Scheffenegger, Richard <Richard.Scheffenegger () netapp com>;
> > tcpdump-workers () lists tcpdump org
> > Subject: Re: Accurate ECN support in tcpdump/libpcap
> >
> > NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the 
> > sender and know the content is safe.
> >
> > On 18/08/2023 09:55, Scheffenegger, Richard wrote:
> > > Hi,
> > >
> > > I’ve been asked to reach out to this mailing list, to gather some feedback around the support for tcpdump to 
> > > properly decode the upcoming (WGLC) Accurate ECN signalling enhancement, which is part of the L4S (low loss, low 
> > > latency, scalable) effort, ultimately culminating in a variant of TCP called TCP Prague:
> > >
> > > Here is the change to tcpdump – adding the additional “A” TCP header
> > > flag bit; Since the ACK bit has traditionally been mapped to “.”, and
> > > the refurbished former Nonce bit #9 in the 12-bit TCP header flags
> > > field has been named “AE” (Accurate ecn Enable), the code changes to
> > > other tools such as Wireshark and Packetdrill are using the mapping
> > > to the character “A” (or decode Accurate ECN stateful into the ACE
> > > counter value of 0..7)
> > Hi,
> >
> > Even if tcpdump prints the "ACK" flag with a ".", "A" is ambiguous precisely because of "ACK".
> > We should use "N" for the new flag, last letter of "Accurate ECN", to avoid this ambiguity, as already suggested in a 
> > PR comment.
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s