> On 5. Sep 2023, at 09:34, Francois-Xavier Le Bail <devel.fx.leb...@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.leb...@orange.fr>; >> tcpdump-workers@lists.tcpdump.org >> Cc: Denis Ovsienko <de...@ovsienko.info>; Guy Harris <ghar...@sonic.net>; >> [...] ; Michael Richardson <m...@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.leb...@orange.fr> >> Sent: Freitag, 18. August 2023 13:20 >> To: Scheffenegger, Richard <richard.scheffeneg...@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-le...@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-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
