--- Begin Message ---
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 ;
tcpdump-workers@lists.tcpdump.org
Cc: Denis Ovsienko ; Guy Harris ;
jyo...@gsu.edu; Casper Andersson ; Eamon Doyle
; Jonas Chianu ; Jesse
Rosenstock ; Michael Richardson ; headshog
; cauldwell.tho...@gmail.com
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)
Hi Francois,
I do not think there is ambiguity here.
Tcpdump - any every tool afterwards - has been using "." 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, 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 (just like with the "." for Ack, which is in common
use throughout 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...
Best regards,
Richard
-Original Message-
From: Francois-Xavier Le Bail
Sent: Freitag, 18. August 2023 13:20
To: Scheffenegger, Richard ;
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-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
