Subject: Re: [MBONED] draft-ietf-mboned-ieee802-mcast-problems-07 submitted, new WGLC to be initiated

From: "Morten V. Pedersen" <[email-masked]>
Date: Thu, 1 Aug 2019 21:34:40 +0200

Sorry for being last minute.

Perhaps relevant: Another issue for layer 2 is what firmware / drivers 
to with multicast traffic. See this patch for ath9k which effectively 
drops multicast traffic once a certain threshold has been reached:
https://patchwork.kernel.org/patch/2687951/

All the best,
Morten

On 7/26/19 8:29 PM, Charlie Perkins wrote:
> Hello folks,
>
> Since the conclusion of the previous WGLC for 
> draft-ietf-mboned-ieee802-mcast-problems, the following changes have 
> been made.
>
>    o  Improved wording in section describing ARPsponge.
>    o  Included new text in Security Considerations to alert about
>       problems regarding Group Key management caused by multicast
>       unreliability and implementation bugs.
>    o  Corrected occurrences of "which" versus "that" and "amount" versus
>       "number".
>    o  Updated bibliographic citations, repaired broken URLs as needed.
>    o  Many more editorial improvements and grammatical corrections.
>
> Some of these changes, while not controversial, deserve at least the 
> opportunity for WG review.  Please take a look at the new draft 
> draft-ietf-mboned-ieee802-mcast-problems-07.
>
> Regards,
> Charlie P.
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Mike McBride <[email-masked]>
Date: Mon, 5 Aug 2019 17:59:11 -0700

Thank you for the info Morten. How about if we simply add the text
from your pointer (and include the pointer) to our section 4:

"The CAB (Content after Beacon) queue is used for beacon-triggered
transmission of buffered multicast frames. If lots of multicast frames
were buffered and this queue fills up, it drowns out all regular
traffic. To limit the damage that buffered traffic can do, try to limit
the queued data to beacon_interval."

Is this specific to OpenWRT and why does it show as State: Not Applicable?

We can add you (and or Felix) to the list of contributors. Sound reasonable?

mike

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Tue, 6 Aug 2019 10:08:10 +0200

Hi Mike,
This is specific to the ath9k driver. So it's an "optimization" that 
some drivers have. Perhaps it should be:

"The CAB (Content after Beacon) queue is used for beacon-triggered
transmission of buffered multicast frames. If lots of multicast frames
were buffered and this queue fills up, it drowns out all regular
traffic. To limit the damage that buffered traffic can do, some drivers 
limit
the amount of queued multicast data to a fraction of the beacon_interval."

Perhaps with a reference to Felix's patch.

I don't know Felix personally - so I cannot say whether he would want to 
appear as an contributor. Otherwise it sounds fine to me.

- M

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 12 Aug 2019 18:34:30 +0000

Hi Charlie,

While working on the shepherd write-up for ieee802-mcast-problems I saw that
there were some unaddressed nits auto-detected by the nits tool:

https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-mboned-ieee802-mcast-problems-07.txt

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

     RFC 2119 keyword, line 639: '...   It is RECOMMENDED that multicast-en...'

  == Missing Reference: 'ICMPv6' is mentioned on line 558, but not defined

I'm not sure whether it's better to remove the single RECOMMENDED usage and
make it a weaker non-normative suggestion or to add the boilerplate, but it
probably should be fixed, and I suppose the ICMPv6 deserves a reference also.

Thanks and regards,
Jake

On 2019-07-26, 11:29, "Charlie Perkins" <[email-masked]> wrote:

    Hello folks,

    
    
    Regards,
    Charlie P.

---

From: Mike McBride <[email-masked]>
Date: Tue, 13 Aug 2019 15:34:34 -0700

Thanks again for bringing this to our attention Morten. You've been
added as a contributor and we added section 4.4 to the new -08:

4.4. Limiting multicast buffer hardware queue depth
The CAB (Content after Beacon) queue is used for beacon-triggered
transmission of buffered multicast frames. If lots of multicast
frames were buffered, and this queue fills up, it drowns out all
regular traffic. To limit the damage that buffered traffic can do,
some drivers limit the amount of queued multicast data to a fraction
of the beacon_interval. An example of this is [CAB].

mike