Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes)

[Brian E Carpenter <[e-mail]>]

On 15/02/2017 07:13, Michael Richardson wrote:
> 
> peter van der Stok <[e-mail]> wrote:
>     > We just did our own mDNS (students did years ago) and have no
>     > experience with
>     > existing code.
>     > What was the precise question?
> 
> It's a good question. What *IS* the question :-)
> 
> We have had the discussion about use of GRASP M_FLOOD vs mDNS for discovery
> of the Join Proxy by the pledge.   We have had some indirect feedback
> ("heresay") from implementers to the effect thta the M_FLOOD stuff
> "is IETF ivory tower nonsense, and we should stop inventing new vanity
> protocols."
> 
> (paraphrased, and unattributed.  Sorry Brian: not my words, and I'm relaying
> them third or fourth-hand, and I sure wish that said people would communicate
> directly, but I think corporate reporting structures get in the way of some
> of that)

Can't hear them due to fingers stuck in ears :-)

Seriously - why do you think I invested considerable personal time in
a prototype? Because I was afraid that we were designing something unrealistic.
But we're not, and I've never found a way that mDNS or DNS-SD could do what
we want.

> There are some esthetic reasons to prefer use of M_FLOOD. This has to do with
> ANIMA being a self-contained system.
> 
> There is also a claim that mDNS is already present in many small
> devices. RFC6763 even says that some ethernet chips can autonomously answer
> mDNS queries when the device in question is in low-power mode!
> 
> But there are some real technical claims about why mDNS does not suit:
> 
> The specific claim is that we can't do unsolicited announcements using
> mDNS.  https://tools.ietf.org/html/rfc6762#section-8, section 8.2 says:
> 
>    A Multicast DNS responder MUST NOT send announcements in the absence
>    of information that its network connectivity may have changed in some
>    relevant way.  In particular, a Multicast DNS responder MUST NOT send
>    regular periodic announcements as a matter of course.
> 
> The rfc6763 DNS-SD process makes it pretty clear that discovery involves a
> query and a reply, and that responses may be multicast such that they are
> easily cached.  6762 says a lot about TTL and how often things are cached.
> 
> I myself do not quite understand the entire interaction.  I observe that
> on networks I am part of that, my mDNS daemon (avahi), always has a list of
> seldom (even never!) used services in it's cache.

Yes, the GRASP model will cache too of course, but non-relay nodes
will only cache (a) what they discovered personally and (b) whatever
was flooded. They will not cache the results of 3rd party discoveries.

Anyway, the GRASP model doesn't just support services. Objectives aren't
services, although they could represent services.

And once again: outside the ACP, there is no need to force GRASP
into every pledge. I would expect COAP or mDNS to be the way a
non-autonomic pledge finds its nearest proxy.

> 
> For instance:
> knothole-[~](2.1.5) mcr 10002 %avahi-browse -vat | wc -l
> 174
> 
> knothole-[~](2.1.5) mcr 10003 %avahi-browse -vat | grep -i Mumble
> + credil IPv6 lapeche                      Mumble Server local
> + credil IPv4 lapeche                      Mumble Server local
> 
> I'm sure that NOBODY has ever asked the network if there was a Mumble
> server around.  Clearly, when it first started, it had a reason to announce
> itself, but that value should have a TTL that after the several hundred days
> of uptime for the "lapeche" machine must have expired.  So I'm unclear how
> reconcile what I read in the specifications ("MUST NOT send regular priodic
> announcements") with what I see in practice.
> 
> 
> It might be that in the end we don't care about the anonimity of the pledge.
> If the pledge can ask the network about Join Proxy, then there is nothing
> to stop us from using mDNS here.
> 
> On the other hand, M_FLOOD is as certainly useable, and is rather simple.
> I had very little problem implementing it myself.

Got any code I could run (on Linux)? At least I could check if my GRASP
can receive those floods correctly. No need to wait for Chicago.

> I also think that every
> Join Proxy is also an ACP node, and so it will want to M_FLOOD about it's
> ACPness, and so I see little downside here.
> 
> I do not have horse in this race:  I just don't want to be ignored by
> developers... who granted, have not come to this conversation.

Running code is the best answer to that.

> (I hear lots of anti-IETF rhetoric from Linux kernel developers, most of whom
> have never posted any question to an IETF list, ever!)

Want to hear some anti-Linux-kernel-developer rhetoric? :-)

But actually, do we care? We don't need anything new in the kernel
to make GRASP/ACP work, I don't think. And do we need anything
for BRSKI?

    Brian