Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03

Markus Stenberg <markus.stenberg@iki.fi> Sat, 02 April 2016 17:47 UTC

Return-Path: <markus.stenberg@iki.fi>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735A112D177 for <dnssd@ietfa.amsl.com>; Sat, 2 Apr 2016 10:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level:
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no
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 EFwPG0gk7G61 for <dnssd@ietfa.amsl.com>; Sat, 2 Apr 2016 10:47:47 -0700 (PDT)
Received: from johanna4.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73C12D0F2 for <dnssd@ietf.org>; Sat, 2 Apr 2016 10:47:47 -0700 (PDT)
RazorGate-KAS: Status: not_detected
RazorGate-KAS: Rate: 0
RazorGate-KAS: Envelope from:
RazorGate-KAS: Version: 5.5.3
RazorGate-KAS: LuaCore: 215 2015-05-29_17-31-22 60ae4a1b4d01d14f868b20a55aced8d7df7b2e28
RazorGate-KAS: Lua profiles 78662 [Jun 02 2015]
RazorGate-KAS: Method: none
Received: from poro.lan (80.220.86.47) by johanna4.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56E91EA2015FBE13; Sat, 2 Apr 2016 20:47:44 +0300
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <EMEW3|643e957a1f3f46c77510cdcca47548f2s31DPG03tjc|ecs.soton.ac.uk|BB679B6D-6F79-4E40-ACA5-B37628A465D6@ecs.soton.ac.uk>
Date: Sat, 2 Apr 2016 20:47:43 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <86F10293-5C6E-447E-B14A-0C41354D4439@iki.fi>
References: <7274B55E-8A4D-4BEE-85F9-C19EC62EEF03@ecs.soton.ac.uk> <BB679B6D-6F79-4E40-ACA5-B37628A465D6@ecs.soton.ac.uk> <EMEW3|643e957a1f3f46c77510cdcca47548f2s31DPG03tjc|ecs.soton.ac.uk|BB679B6D-6F79-4E40-ACA5-B37628A465D6@ecs.soton.ac.uk>
To: Chown Tim <tjc@ecs.soton.ac.uk>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnssd/ItqPlVBA5utMIfnMToixGLqmInY>
Cc: dnssd@ietf.org
Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Apr 2016 17:47:50 -0000

I was on vacation during WGLC (good timing - I was leaving home when it started, lost my laptop charger early on the trip and by the time I got home official WGLC window was done). Disclaimer: This is a beer-powered remotely participating hobbyist commentary based on reading my own earlier comments + draft deltas, and does not consititute a full review. Sorry.

Anyway..

Section 1 - isn’t this scheme essentially aiming at causing more multicast duplication too? (e.g. given ‘home’ DNS-SD browse domain, if we send unicast for each sublink.home, we wind up with N multicasts per single logical request).

Section 4.5.1 - I wonder about positive TTL limiting. Because if device ‘moves’, it most likely will either
a) have two different names (foo.link1.home, foo.link2.home), or
b) one name with two addresses (foo.link1.home A 192.168.1.1, foo.link1.home A 192.168.1.2).

Happy Eyeballs-ish should take care of either in practise, so I am against positive TTL limiting. Negative TTL limiting makes sense except in some DoS scenarios which can be circumvented to some degree by e.g. limiting total # of multicasts send by hybrid proxy over time interval per link or something.

Overall, I find the text bit too prescriptive (‘do it this way’), as it forbids you from having a service that e.g. only supports printer and apple TV services, and proactively queries for them rarely => no need for extra traffic by whatever occurs on wire, and the content could be even pushed to e.g. normal DNS-SD using DNS Update or equivalent ( draft-lemon-homenet-naming-architecture-00.txt has strawman proposal about this, and I thought about it years ago too but never got around to implementing or specifying it ). Another scheme would be completely passive node that did clever things with e.g. L2 availability to detect when stuff drops off link ‘fast enough’.

Second major missing piece from my point of view is the section 6.4 paragraph 2 - stitching together of zones. As it is, the single logical request => N multicasts propagation sounds somewhat undesirable to me.

While not having reread the whole thing again (see sorry above), my earlier nits are mostly addressed, I cannot find anything particularly broken (see disclaimer about beer), and I think it is ‘ready’ for some  definition of ready. I would not personally want it as a choice for any large network though, due to it forcing exactly one operating model for the mdns->dnssd translation which I am no longer convinced is actually optimal. For home network purposes this works, but I would be leery of saying this is ’the way to do it’ without some simulation results in e.g. enterprise or university deployment scenarios.

Cheers,

-Markus