Re: [Cerowrt-devel] Multicast IHUs [was: perverse powersave bug with sta/ap mode]

[Dave Taht <dave.taht@gmail.com>]

On Thu, Apr 28, 2016 at 10:10 AM, Juliusz Chroboczek
<jch@pps.univ-paris-diderot.fr> wrote:
>> 1) Well, I have suggested that IHU messages actually be unicast rather
>> than bundled with the hello.
>
> Yes, you have suggested that before.  I answered I would implement that if
> somebody volunteered to do an experimental evaluation.  Nobody volunteered.

We do need to build the size of the community.

I am perpetually giving talks about wifi in front of various
audiences. Making the comment:

"how many of you use wifi, hands up"

Always gets a laugh (from those paying attention)

(sometimes I'm sufficiently annoyed at those not paying attention to
ask "those of you that are paying attention, hands up")

"How many of you understand how it works?"

and nearly all the hands go down.

"Why is this not a problem?", and then I launch into the talk....

I guess it would be better to collect my(our) rants, problems, and
arguments, tone them down, and get something about - "wifi, the
dominant paradigm" into more widely read publications than these
mailing lists. The recent conference on wifi in DC had some data like
"3 billion wifi devices shipped last year".


>> That would help somewhat in this case.
>
> That's my intuition too, but I've learned to be wary of my intuitions.
> Doing wireless stuff without careful evaluation is not something I'll do
> again.

Yep. Need more people on these problems. I promise to care more after
we cut latencies under load on wifi by 2 orders of magnitude on 3
chipsets.

>> 2) A protocol that needs "always listening" capability could signal
>> the underlying stack to "make sure" these packets hit the air, and one
>> that also wants "please be lossy" capabl
>> I leave the actual implementation of that request to the fantasies of
>> the authors - a new dscp codepoint or three?
>> /me ducks
>
> No need to duck, Dave, it's very similar to what was done with UDP-Lite,
> where the use of a specific value in the protocol field signals the link
> layer not to discard corrupted frames.  I've never seen it in the wild,
> I wonder why.

Hmm.. In babel's case, switching it to udp-lite would be like 1 line
of code. Not that it would help (unless the "don't multicast this"
code is explicitly filtering out normal udp only), and the flag day
would be no fun, but certainly the basic properties of udplite aren't
entirely unaligned... I have done tests of udplite (I have a patch
available for it for netperf if anyone wants it) and over ipv6, at
least, it did seem to be quite routable over multiple hops.
*link-local* udp-lite should "just work".

>
>> 4) And ya know - it might merely be a (sadly common) bug. Everybody's
>> supposed to wake up for the multicast beacons and get a notification
>> there's more data to come.
>
> Yes, it's obviously a bug.  Just like you, I'm not suprised -- ad-hoc mode
> and power save is the kind of thing that's never tested.  I suggest you
> disable power saving on all your nodes and be done with it.

That does not bode well for normal homenet users in the long run.

> -- Juliusz



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org