tcpdump mailing list archives
Re: Accurate ECN support in tcpdump/libpcap
From: Francois-Xavier Le Bail <devel.fx.lebail () orange fr>
Date: Tue, 5 Sep 2023 09:34:53 +0200
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).
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. 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
Current thread:
- Accurate ECN support in tcpdump/libpcap Scheffenegger, Richard via tcpdump-workers (Aug 29)
- <Possible follow-ups>
- Re: Accurate ECN support in tcpdump/libpcap Scheffenegger, Richard via tcpdump-workers (Aug 29)
- Re: Accurate ECN support in tcpdump/libpcap Francois-Xavier Le Bail (Sep 05)
- Re: Accurate ECN support in tcpdump/libpcap Scheffenegger, Richard via tcpdump-workers (Sep 05)
- Re: Accurate ECN support in tcpdump/libpcap Michael Tuexen (Sep 05)
- Re: Accurate ECN support in tcpdump/libpcap Francois-Xavier Le Bail (Sep 05)
- Re: Accurate ECN support in tcpdump/libpcap Michael Richardson (Sep 03)
- Message not available
- Re: Accurate ECN support in tcpdump/libpcap Scheffenegger, Richard via tcpdump-workers (Aug 31)
- Message not available
- Re: Accurate ECN support in tcpdump/libpcap Scheffenegger, Richard via tcpdump-workers (Sep 03)