steve-o
commented
1 year ago Risso's values may have been test values pre-publication of "pgmcc: a TCP-friendly single-rate multicast congestion control scheme https://dl.acm.org/doi/10.1145/347059.347390". I believe TIBCO SmartPGM may have conflicting packet details for congestion control too.
To some degree the protocol is obsolete as it doesn't scale at modern networking speeds and an alternative is required, ideally based upon HTTP/3 research and UFTP pragmatic usage. Recent developments have been on a multicast extension to QUIC, with great interest in the online learning (MOOC) space.
- https://uftp-multicast.sourceforge.net/
- https://www.ietf.org/staging/draft-jholland-quic-multicast-00.html
On Tue, Aug 22, 2023 at 4:47 PM Guy Harris @.***> wrote:
The I-D doesn't say what the Type field value is for ACK packets (and, as far as I can tell, never did).
Luigi Risso's PGM implementations for FreeBSD, with PGMCC, and patch for tcpdump at https://web.archive.org/web/20020302084503/http://info.iet.unipi.it/~luigi/pgm-code/ have the Type field value as 11/0x0B, as does the code submitted to tcpdump for its dissector.
This code, as well as the Wireshark dissector for PGM, has it as 13/0x0D, as does a PGMCC capture attached to https://gitlab.com/wireshark/wireshark/-/issues/4798.
Are they just two different codes for the same packet (which is what I made the tcpdump PGM dissector handle, and what I'm going to make the Wireshark PGM dissector handle)?
Or are they two different flavors of ACK that have to be dissected differently?
— Reply to this email directly, view it on GitHub https://github.com/steve-o/openpgm/issues/75, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB7EQ7DCLJMLUWQBTYQPITXWULGZANCNFSM6AAAAAA32PHL6Y . You are receiving this because you are subscribed to this thread.Message ID: @.***>
The I-D doesn't say what the Type field value is for ACK packets (and, as far as I can tell, never did).
Luigi Rizzo's PGM implementations for FreeBSD, with PGMCC, and patch for tcpdump at https://web.archive.org/web/20020302084503/http://info.iet.unipi.it/~luigi/pgm-code/ have the Type field value as 11/0x0B, as does the code submitted to tcpdump for its dissector.
This code, as well as the Wireshark dissector for PGM, has it as 13/0x0D, as does a PGMCC capture attached to https://gitlab.com/wireshark/wireshark/-/issues/4798.
Are they just two different codes for the same packet (which is what I made the tcpdump PGM dissector handle, and what I'm going to make the Wireshark PGM dissector handle)?
Or are they two different flavors of ACK that have to be dissected differently?