Re: [v6ops] draft-ietf-6man-grand : saving lookups

[Warren Kumari <[e-mail]>]

On Sun, Aug 9, 2020 at 3:13 PM Bob Hinden <[e-mail]> wrote:
>
> Pascal,
>
> > On Aug 9, 2020, at 11:56 AM, Pascal Thubert (pthubert) <pthubert=[e-mail]> wrote:
> >
> > We have some Ted;
> >
> > In large meetings we measured way above 100 ND multicast messages per second on the wire, for 90 minutes in a row.
>
> What does “way above 100” mean?   101, 1000, 10000, ?

Do you remember IETF 99 (July 16-21, 2017,  Prague, Czech Republic,
1230 onsite attendees) and the Terrible, Horrible, No Good, Very Bad
Network? This was on the order of 2,000 broadcast / multicast packets
per second.
https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-11,
Section 3.2.4.  Spurious Neighbor Discovery - "Around 2,000 broadcasts
per second have been observed at the IETF NOC during face-to-face
meetings."

Apart from destroying the wireless, this kills mobile device battery life....

>
> 100 per second doesn’t seem excessive to me.  What percentage of overall messages was that?  How many nodes on the link?

For many networks, the broadcast/multicast load DECREASES as the
number of nodes INCREASES. For something like the IETF network, we are
constantly getting background radiation from scanners, etc. This leads
to neighbor discovery / ARP requests for unused space, leading to B&M.
Once the network gets "fuller" the neighbor discovery traffic drops
significantly....

See also https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-11
, Section 4, esp 4.6, Section 5.1, and, well, all of the other
sections too....


>
> Bob
>
>
> >
> > This was on the wire because we use proprietary tech to dampen the wireless side, things like ND proxy but based on snooping for the lack of a better information.

Yes, modern wifi devices do many many non-standard (and often
blackmagic/poorly documented) things to try and mitigate these issues.
Unfortunately they often fail in bizarre and difficult to troubleshoot
ways...

> >
> > I asked for the figures at the last 2 in person IETF meetings but never got them. First time I asked too late, there needs to be due process to guarantee anonymity. Not sure if they were captured in Singapore and if so where they are.

Who / where did you ask for this? And what exactly were you wanting to
collect -- a simple rate of broadcast / multicast would probably have
been easy, and not privacy invasive...
W

> >
> > Take care,
> >
> > Pascal
> >
> >> Le 9 août 2020 à 18:04, Ted Lemon <[e-mail]> a écrit :
> >>
> >> Do we have data that indicates that this would be an improvement?
> >>
> >>> On Aug 9, 2020, at 11:47, Philip Homburg <[e-mail]> wrote:
> >>>
> >>> 
> >>>>
> >>>> So what I'm after is the host behavior of "not onlink" for the
> >>>> lookup phase, the router behavior of onlink for the redirect phase,
> >>>> and the L bit set iff the link is P2P or a transit. E.g., in a
> >>>> distributed fabric, all addresses "reside on-link and can be reached
> >>>> directly without going through a router" and yet we want to avoid
> >>>> broadcast lookups.
> >>>
> >>> Suppose we have a no-multicast bit, that tells a host to send traffic to
> >>> its default router when it doesn't have a neighbor in the NC cache.
> >>>
> >>> It is not clear to me how the semantics would be different from clearing the
> >>> L-bit, but if you think there are considerable differences, why no write
> >>> a draft that describes the use of such a bit.
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> [e-mail]
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf