Re: Wed Sep 7 at 9:30am Pacific/4:30pm UTC is September's multicast-cg meeting

Hi Lenny,

Some comments inline with [JH].

On 09-23, 7:02 AM, "Leonard Giuliano" <lenny@juniper.net> wrote:

Catching up and looking through the notes from the Aug mtg:

***
"Separately, some interesting developments on multicast itself. Feedback 
from one of the network operators using it for TV delivery. Problem with 
IGMPv3, when they see a IGMPv1 packet it downgrades to IGMPv1, which stops 
SSM from working. RFC 3376 (IGMPv3) section 7.2.2 says you MAY suppress 
further IGMPv3 membership reports when you see IGMPv1 report on the LAN. 
We have a case for changing the may to a should not, and submitting a 
patch to Linux. Make multicast more reliable on home networks. Thanks Max 
for pointing out the relevance. Its timely to get the spec changed since 
the PIM wg is working on promoting IGMPv3 to a full internet standard 
instead of its current proposed standard status."
***

It's been a while, but last I checked the IGMPv3 spec actually did a 
decent job with backards compat.  If a v3 router receives a v2 join, it 
will drop to v2, *but only for that particular group*.  All other groups 
will remain on v2 for the LAN.  Further, the routers should ignore any ASM 
behavior in the SSM range.  That means IGMPv1/2 reports, (*,g) joins, PIM 
registers, MSDP SAs for any groups in 232/8 should always be ignored.  At 
least that's the behavior on Juniper and Cisco routers, and I would 
assume other vendors as well.

----
[JH] You're saying maybe it's an implementation problem more than a
spec problem?

I do see non-normative language that sounds like what you're saying
about routers using a per-group compatibility mode, in the first
paragraph of 7.3.2.

But I also see that 7.2.2 of RFC 3376 certainly permits a problematic
behavior with its natural reading, I didn't see exceptions listed there
for ignoring 232 or anything.  The whole text of that section is:

7.2.2. In the Presence of Older Version Group Members

   An IGMPv3 host may be placed on a network where there are hosts that
   have not yet been upgraded to IGMPv3.  A host MAY allow its IGMPv3
   Membership Record to be suppressed by either a Version 1 Membership
   Report, or a Version 2 Membership Report.

I'd argue an older host at least SHOULD NOT DoS a newer capability, so
it also looks like a spec problem to me on at least one point, and
perhaps there are more.

It might be helpful to get a walkthrough of the expected behavior written
down with references, or a normative test suite or something.  I did not
find it trivial to extract the expected corner case behavior from the spec. 
----

Now that's the behavior of v2-v3 interop.  TBH, I never looked at v1-v3 
interop as I kind of assumed v1 went away in the late 90s.  V2 pretty 
quickly got implemented on host stacks, replacing v1, while v3 took a bit 
longer, but should be pretty pervasive by this point.  For that reason, I 
wonder if this is a red herring- an issue someone saw in a lab years ago 
and decided v3 was not viable.  Also, wondering if they could have been 
hitting a bug, not a spec issue.  Anyway, if you have more details on what 
they saw, and why they have v1 hosts in the first place that they have 
directly connecting to their routers, I'd be very curious.

----
Apparently there's several devices that are locally popular still, and
within the last few years drove the largest proportion of user complaints
in a large consumer network, with the most common symptom being that the
TV service stops working (permanently until a manual reset for that
household) whenever one of a few popular printer brands gets turned on.
I hear they're currently changing their TV service to unicast as a
result.

I have indeed also seen this in lab before, but ignored it at the time
since it was possible to work around with settings (IIRC there's a sysctl
to force v3 regardless in the linux router that wasn't the default).  But
hearing about this made me realize it was a much bigger problem for
deployment than I had realized.
----

On Wed, 7 Sep 2022, Holland, Jake wrote:

| 
| 
| Hi multicast-cg,
| 
| Today's meeting will be at 4:30pm UTC (9:30am Pacific), I hope
| to see you then, and sorry for the short notice on this reminder.
| 
| Proposed agenda:
| - 5 min: welcome and agenda-bash
| - 20 min: Status update & discussion
|   - aioquic implementation status (https://urldefense.com/v3/__https://github.com/MaxF12/aioquic__;!!NEt6yMaO-gk!EiDh9ki38445CaAJMxyk2Oo92spSXmZaUgnzlJgkmHqBeSPkpRCCU58vRHoj6rpiJT3Z-hDnOOsP_WNw$  )
| - 20 min: TPAC 2022
|   - I'll be there in person
|   - breakout session proposed (https://urldefense.com/v3/__https://www.w3.org/wiki/TPAC/2022/SessionIdeas*Multicast__;Iw!!NEt6yMaO-gk!EiDh9ki38445CaAJMxyk2Oo92spSXmZaUgnzlJgkmHqBeSPkpRCCU58vRHoj6rpiJT3Z-hDnOMKRbIqR$  )
| - 10 min: Next steps
| 
| Best,
| Jake
| 
| PS: here's the notes and video from last month's meeting:
| https://urldefense.com/v3/__https://docs.google.com/document/d/1vop1sEctzAGANR6zG37_6QxnUuP-z3R6-LdWXIQ-yfk__;!!NEt6yMaO-gk!EiDh9ki38445CaAJMxyk2Oo92spSXmZaUgnzlJgkmHqBeSPkpRCCU58vRHoj6rpiJT3Z-hDnOFW8bvKC$

| https://urldefense.com/v3/__https://youtu.be/ShVX7_jacyY__;!!NEt6yMaO-gk!EiDh9ki38445CaAJMxyk2Oo92spSXmZaUgnzlJgkmHqBeSPkpRCCU58vRHoj6rpiJT3Z-hDnOAEPRM_l$

| 
| Thanks again to Chris Needham for the great notes.
| 
| ------
| 
| Meeting Coordinates:
| 
| Monthly Multicast W3C Community Group Meeting
| Hosted by Jake Holland
| 
| https://urldefense.com/v3/__https://akamai.webex.com/akamai/j.php?MTID=m46e51f96f443eda24eed93ad804cb8df__;!!NEt6yMaO-gk!EiDh9ki38445CaAJMxyk2Oo92spSXmZaUgnzlJgkmHqBeSPkpRCCU58vRHoj6rpiJT3Z-hDnOFLvPbRp$

| Wednesday, Sep 7, 2022 9:30 am | 1 hour | (UTC-07:00) Pacific Time (US & Canada)
| Occurs the first Wednesday of every month effective 1/5/2022 from 9:30 AM to 10:30 AM, (UTC-07:00) Pacific Time (US & Canada)
| Meeting number: 145 142 6461
| Password: yay-multicast!
| Agenda: Recurring monthly meeting for W3C Multicast Community Group (https://urldefense.com/v3/__https://www.w3.org/community/multicast/__;!!NEt6yMaO-gk!EiDh9ki38445CaAJMxyk2Oo92spSXmZaUgnzlJgkmHqBeSPkpRCCU58vRHoj6rpiJT3Z-hDnOK8anJVh$  ).
| 
| A specific agenda should go out ahead of the meeting on the public mailing list:
| https://urldefense.com/v3/__https://lists.w3.org/Archives/Public/public-multicast/__;!!NEt6yMaO-gk!EiDh9ki38445CaAJMxyk2Oo92spSXmZaUgnzlJgkmHqBeSPkpRCCU58vRHoj6rpiJT3Z-hDnOEKdp13y$

| 
| The agenda outline is generally:
| - Agenda-bashing
| - Present updates since prior month
| - Discuss next steps
| - Schedule a working session to work on the next steps (usually)
| 
| Please note:
| 
| This meeting will be recorded if nobody withholds consent, as covered by the latest draft process guidelines:
| https://urldefense.com/v3/__https://www.w3.org/Consortium/Process/Drafts/*meeting-recording__;Iw!!NEt6yMaO-gk!EiDh9ki38445CaAJMxyk2Oo92spSXmZaUgnzlJgkmHqBeSPkpRCCU58vRHoj6rpiJT3Z-hDnOPySZLcE$

| 
| The purpose of recording is to aid with minutes, enable later review of comments, and to help future new or prospective group members get oriented. The video will be posted to Youtube and made publicly available without an expiration. However, if requested by recorded participants, sections of the public recording will be redacted to their satisfaction as needed, before or after publication (though after publication of course there may be copies outside our control). A link to the recording will be kept in the meeting log here (and updated if replaced with a redacted recording): https://urldefense.com/v3/__https://github.com/w3c/multicast-cg/tree/main/meetings__;!!NEt6yMaO-gk!EiDh9ki38445CaAJMxyk2Oo92spSXmZaUgnzlJgkmHqBeSPkpRCCU58vRHoj6rpiJT3Z-hDnOMBZtoS4$

| 
| This is a W3C Community Group meeting, so it's to operate under the W3C Code of Ethics and Professional Conduct: https://urldefense.com/v3/__https://www.w3.org/Consortium/cepc/__;!!NEt6yMaO-gk!EiDh9ki38445CaAJMxyk2Oo92spSXmZaUgnzlJgkmHqBeSPkpRCCU58vRHoj6rpiJT3Z-hDnOE4fT2wc$

| 
| Join by video system
| Dial 1451426461@akamai.webex.com
| 
| Join by phone
| 1-408-792-6300 Call-in toll number (US/Canada)
| 1-877-668-4490 Call-in toll-free number (US/Canada)
| 
| Access code: 145 142 6461
| 
| 
|

Received on Friday, 23 September 2022 17:18:27 UTC