Re: Accurate ECN support in tcpdump/libpcap

[Michael Tuexen <michael.tuexen () lurchi franken de>]

> On 5. Sep 2023, at 09:34, Francois-Xavier Le Bail <devel.fx.lebail () orange fr> wrote:
>
> 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·)
> ------------------------^
It uses A for ACK and AE:
https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-tcp.c#L854
But this notation is used in a position dependent way.

Best regards
Michael
> > 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).
>
> 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.
>
> > 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.
Wireshark uses the first character...

Best regards
Michael
> 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.
> _______________________________________________
> 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


_______________________________________________
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