Re: Accurate ECN support in tcpdump/libpcap

["Scheffenegger, Richard via tcpdump-workers" <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: "Scheffenegger, Richard" <Richard.Scheffenegger () netapp com>
>
> Date: Tue, 29 Aug 2023 14:34:12 +0000
>
>
> 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>; jyoung () gsu edu; Casper Andersson 
> <casper.casan () gmail com>; Eamon Doyle <eamonjd () arista com>; Jonas Chianu <jchianu () onx-jchianu-02 ciena com>; 
> Jesse Rosenstock <jmr () google com>; Michael Richardson <mcr () sandelman ca>; headshog <craaaaaachind () gmail com>; 
> cauldwell.thomas () 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 <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.
>
> --- End Message ---
_______________________________________________
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