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

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



On Tue, Aug 6, 2019 at 1:08 AM Morten V. Pedersen <[email protected]> wrote:
>
> 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
>
> On 8/6/19 2:59 AM, Mike McBride wrote:
> > 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
> >
> > On Thu, Aug 1, 2019 at 12:34 PM Morten V. Pedersen <[email protected]> wrote:
> >> 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 protected]
> >>> https://www.ietf.org/mailman/listinfo/mboned
> >> _______________________________________________
> >> MBONED mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/mboned

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned