[tcpdump-workers] Re: upgrade to mailman3
--- Begin Message --- If the mailing list is working again, I'd like to receive some constructive criticism on pull request #999: https://github.com/the-tcpdump-group/tcpdump/pull/999 As well as pull request #1210 for libpcap, to also allow access to all tcp header flags using the existing "tcp[tcpflags]" grammar, and adding the tcp-ae flag. https://github.com/the-tcpdump-group/libpcap/pull/1210 Richard Scheffenegger --- 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
[tcpdump-workers] Re: Accurate ECN support in tcpdump/libpcap
--- Begin Message --- Hi Francois-Xavier! > I think there's an ambiguity here. I respect your opinion on this; It would be nice to hear the opinions of more people using and improving tcpdump. Currently it seems to me, that only you and I have particularly strong convictions about the abbreviation letter... > If you think this is a problem for the new flag, have you considered > modifying the two tools you mention with two small patches? It's not the change in packetdrill by itself that I'm worried about, but all the deployed and productive regression testing scripts already using the "A" (and 0..7) notation. At this stage it probably would be easier to sed "s/N/A/" on the tcpdump output when creating a new script from tcpdump captures. My packetdrill scripts tend to use the "A" notation only during the handshake and then use the numerical notation supported by packetdrill. But I know that many of the scripts in the Linux world don't make use of the numerical notation for in-session header flags. Adding the maintainer of packetdrill and the author of the wireshark patch for their view on this. > 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. From these, I could accept the "N" for the historic precedent (Nonce Sum bit) and "Accurate EC[N]" if others support that too. I maintain that "A" is most appealing to me, the other alternatives I'm not really fond of; BTW - TCP Prague is more than just the AccECN signalling; you have changed IP ECN use (ECT(1) instead of ECT(0)), but most importantly, the congestion control mechanisms is based around DCTCP, and Loss recovery is based upon RACK (as a typical starting point) > 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. Indeed. Technically, Jul 2022 to Jul 2023 is 12 months, which fits with couple of months. Prior to that, the tcpdump project has had no formal knowledge... Originally (2020) I had not properly set up the git repository and was only reminded about this at the IETF114 hackathon. Denis email response to me was unfortunately earmarked as junk due to the long time difference of July 2022 to October 2022 - I presume the filter wasn't expecting an answer after almost 3 months... I only unburied it during the IETF117 hackathon. And matters got delayed a bit more with the recent issues around this lists mailman. In order to make some progress, I suggest to split off the part of the patch, which allows access to all 12 TCP header flags, and submit that separately; This could be committed together with the adjacent change to libpcap (the parser decoding the literal "tcp[tcpflags]" string to provide also all 12 flag bits. Would that be agreeable? Richard Scheffenegger -Original Message- From: Francois-Xavier Le Bail Sent: Dienstag, 5. September 2023 09:35 To: Scheffenegger, Richard ; tcpdump-workers@lists.tcpdump.org Subject: Re: [tcpdump-workers] 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 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 ; > tcpdump-workers@lists.tcpdump.org > Cc: Denis Ovsienko ; Guy Harris > ; [...] ; Michael Richardson ; > [...] > 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 Cong
[tcpdump-workers] Re: Accurate ECN support in tcpdump/libpcap
--- Begin Message --- I've been using Tim Shepard xplot together with tcptrace (srtt plots) for years and I'm quite happy with it. Since xplot uses (modified) gnuplot language, I believe you meant to say that tcpdump2xplot was not updated? https://man.archlinux.org/man/tcpdump2xplot.1.en Since tcptrace uses libpcap, I don't see that particular thing as an issue, really; and when tcpdump2xplot was broken before (but hardly ever used, since there are better workflows IMHO), is this really an issue. Implementing a full json dumper sounds like overkill to me - and those old tools don't parse json anyway... To reiterate: A number of other tools which have been improved to decode Accurate ECN (TCP header flags) from the full set of 12 flag bits are already using a shorthand notation of "A" for the AE bit; and, if they decode tcp streams in a stateful manner, decode the ACE field (comprised of the TCP header flags AE, CWR and ECE) into an octal / decimal number 0..7. IMHO the main point to answer in this group is, if using "A" - like what packetdrill and wireshark are doing - would confuse anyone to mistakenly think the "ACK" flag - typically abbreviated "." could be confused with the "AE" flag. I strongly believe that this is not the case, as the precedent with using "." for the ACK flag is in widespread use; and people mistakenly thinking the "A" abbreviation stands for ACK would find out the misconception extremely rapidly (and probably remember that much better than otherwise). Having tcpdump use a different abbreviation would IMHO much more likely contribute to confusion by people using a diverse set of tools. And yes, I am very sorry to have dropped the ball on this with the tcpdump project approximately 2 years ago, when updating the tooling was an area of very active development Richard Scheffenegger -Original Message- From: Michael Richardson Scheffenegger, Richard wrote: > Tcpdump - any every tool afterwards - has been using "." for ACKs. Hi, so there have been some tools which have parsed the tcpdump "TCP" output in the past, and there have been small variations in the output, and often we've broken those tools. One such tool was Tim's https://man.archlinux.org/man/xplot.1.en which I think we broke and it never got quite fixed, and I am forever sad. The best situation would be that you'd add a --tcp-json option and then dump TCP stuff in JSON, with a really long line and minimal spaces. That might be too much work... it's always that situation for small incremental changes. So I really don't have any good advice. --- 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
[tcpdump-workers] Re: Accurate ECN support in tcpdump/libpcap
--- Begin Message --- I've been using Tim Shepard xplot together with tcptrace (srtt plots) for years and I'm quite happy with it. Since xplot uses (modified) gnuplot language, I believe you meant to say that tcpdump2xplot was not updated? https://man.archlinux.org/man/tcpdump2xplot.1.en Since tcptrace uses libpcap, I don't see that particular thing as an issue, really; and when tcpdump2xplot was broken before (but hardly ever used, since there are better workflows IMHO), is this really an issue. Implementing a full json dumper sounds like overkill to me - and those old tools don't parse json anyway... To reiterate: A number of other tools which have been improved to decode Accurate ECN (TCP header flags) from the full set of 12 flag bits are already using a shorthand notation of "A" for the AE bit; and, if they decode tcp streams in a stateful manner, decode the ACE field (comprised of the TCP header flags AE, CWR and ECE) into an octal / decimal number 0..7. IMHO the main point to answer in this group is, if using "A" - like what packetdrill and wireshark are doing - would confuse anyone to mistakenly think the "ACK" flag - typically abbreviated "." could be confused with the "AE" flag. I strongly believe that this is not the case, as the precedent with using "." for the ACK flag is in widespread use; and people mistakenly thinking the "A" abbreviation stands for ACK would find out the misconception extremely rapidly (and probably remember that much better than otherwise). Having tcpdump use a different abbreviation would IMHO much more likely contribute to confusion by people using a diverse set of tools. And yes, I am very sorry to have dropped the ball on this with the tcpdump project approximately 2 years ago, when updating the tooling was an area of very active development Richard Scheffenegger -Original Message- From: Michael Richardson Scheffenegger, Richard wrote: > Tcpdump - any every tool afterwards - has been using "." for ACKs. Hi, so there have been some tools which have parsed the tcpdump "TCP" output in the past, and there have been small variations in the output, and often we've broken those tools. One such tool was Tim's https://man.archlinux.org/man/xplot.1.en which I think we broke and it never got quite fixed, and I am forever sad. The best situation would be that you'd add a --tcp-json option and then dump TCP stuff in JSON, with a really long line and minimal spaces. That might be too much work... it's always that situation for small incremental changes. So I really don't have any good advice. --- 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
[tcpdump-workers] Re: Accurate ECN support in tcpdump/libpcap
--- 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
[tcpdump-workers] Accurate ECN support in tcpdump/libpcap
--- Begin Message --- Hi, I’ve been asked to reach out to this mailing list, which, after much ado (temporarily unreactive mailman) I hope I can finally do. The goal is 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) https://github.com/the-tcpdump-group/tcpdump/pull/999 This change to the parser in libpcap allows access to all 12 bits when using the sample from the man page like this tcpdump 'tcp[tcpflags] & (tcp-rst|tcp-ack) == (tcp-rst|tcp-ack)' to also include the ‘tcp-ae’ flag: https://github.com/the-tcpdump-group/libpcap/pull/1210 If you are interested in learning more about L4S: https://datatracker.ietf.org/doc/rfc9330/ Accurate ECN requirements: https://datatracker.ietf.org/doc/rfc7560/ Accurate ECN signaling protocol: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn The adjacent patch to packetdrill for decoding and encoding AccECN (stateful): https://github.com/google/packetdrill/commit/77ab15806a56de226345fbe1910139829e431fe0 And the adjacent patch to wireshark – including the TCP Option of Accurate ECN https://gitlab.com/wireshark/wireshark/-/merge_requests/7816/diffs?commit_id=ecefcf880121961c03d2ec05ad378c82e951e0a2 Richard Scheffenegger --- 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
