> 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:
But this notation is used in a position dependent way.

Best regards
>> 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
> 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

Reply via email to