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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 14 February 2017 19:40 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1E8129717 for <anima-bootstrap@ietfa.amsl.com>; Tue, 14 Feb 2017 11:40:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHLhcI2uxKIL for <anima-bootstrap@ietfa.amsl.com>; Tue, 14 Feb 2017 11:40:33 -0800 (PST)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08257129420 for <anima-bootstrap@ietf.org>; Tue, 14 Feb 2017 11:40:33 -0800 (PST)
Received: by mail-it0-x236.google.com with SMTP id k200so20245243itb.1 for <anima-bootstrap@ietf.org>; Tue, 14 Feb 2017 11:40:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Oc9BPaM/s4EpRs+VzdUdj9HX6g0rQlRJoJbXtQdikx4=; b=Dx4MMGbFHJKV1eBfjOpSAJu9gvEHBPHAVGVvcDKxfLKUzPsceK7L33+sHfSRt3tSGn gVf4uoHrL6wspO2hQVfTDq/YuB3US0QyhNlkQJlXnazw2+uyuXOxEghwb600b9XiNbJE IVN4gDKViFUIGeliyq3XZ/N1LbNmdvkcttSiYL9twySDSVbo3l93q776kCRrKs1rl5D0 Opr3E3je15gFZ5/pgktCPY+VVCZeYCDu/KWQL5f2z70TH3ir15mViMStFPkO0A0rZCzY zRdCgzDzbxMhjcjix3OS9YNtmRW6jdx+36HPvOR+bq2W2i1noVZ7GdVvSJCgd++aVEOJ vtKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Oc9BPaM/s4EpRs+VzdUdj9HX6g0rQlRJoJbXtQdikx4=; b=AB7a6eaToYu9Hp5pgaDpxc8Mew0TChp5cePYSmOgLN8JLwleRzrIeH/egG3Er3qB8v lf/9jnViS5zDrvtej+7Whfa6/IhyABhDGSekJKG5SPTefbFE97AWI4eR9hpUgAAe1v+8 ZNMTbPWyedoJ6I5W2PdX2TwC3frTYUHMryzf0D5GMjtmXzueioPNzEAIzwHKmIJ1IcHz G9jT1BXqvTt+TCMkzeFXu7p64o8t5p7GE+6w9QMGWK8bhTqa3hCsETWs6P5imGTkd3a2 dF0PfSMjVcpHzKUz6YkhSsZSLEbETEOeDfs6zecpFjxpjWqgH6bH/QSbI7M5kPO9g0OA TuJQ==
X-Gm-Message-State: AMke39lfaQDJpYaDO0m/TcHx2BOUHKOxSIim/GdhXfDHJk6H9FqkdEIQhrOUa/EP6cweXg==
X-Received: by 10.99.97.196 with SMTP id v187mr22359329pgb.175.1487101232206; Tue, 14 Feb 2017 11:40:32 -0800 (PST)
Received: from [192.168.178.21] ([118.148.78.74]) by smtp.gmail.com with ESMTPSA id t15sm2837648pgn.18.2017.02.14.11.40.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 11:40:31 -0800 (PST)
To: anima-bootstrap@ietf.org
References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <9e98b251-e66f-a898-2548-962c07d3a380@gmail.com>
Date: Wed, 15 Feb 2017 08:40:32 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <18113.1487095987@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/M4xgP1y5Bxzwb6phz_mtO8zGEp8>
Cc: Toerless Eckert <tte@cs.fau.de>, consultancy@vanderstok.org
Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes)
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2017 19:40:35 -0000

On 15/02/2017 07:13, Michael Richardson wrote:
> 
> peter van der Stok <stokcons@xs4all.nl> 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