Re: [dnssd] multicast over wireless links

Robert Cragie <robert.cragie@gridmerge.com> Thu, 24 July 2014 19:55 UTC

Return-Path: <robert.cragie@gridmerge.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FF81A0ACF for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 12:55:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 008EplCx5cc8 for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 12:55:32 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan15.extendcp.co.uk [79.170.45.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628831A0AC8 for <dnssd@ietf.org>; Thu, 24 Jul 2014 12:55:32 -0700 (PDT)
Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g64.hi.local with esmtp (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1XAP6x-0007zK-5R for dnssd@ietf.org; Thu, 24 Jul 2014 20:55:31 +0100
Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1XAP6t-0002hh-SC for dnssd@ietf.org; Thu, 24 Jul 2014 20:55:30 +0100
Received: from host86-163-16-160.range86-163.btcentralplus.com ([86.163.16.160] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XAP6t-0006Tq-HH for dnssd@ietf.org; Thu, 24 Jul 2014 20:55:27 +0100
Message-ID: <53D164B1.3000909@gridmerge.com>
Date: Thu, 24 Jul 2014 20:55:29 +0100
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: dnssd@ietf.org
References: <421C934C-F0CB-4FBF-83ED-04A48526D5F2@gmail.com> <53D15182.1040307@gridmerge.com> <324FDCE8-C812-45A4-BA47-D35ACC896A36@nominum.com>
In-Reply-To: <324FDCE8-C812-45A4-BA47-D35ACC896A36@nominum.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms010100070400050809030701"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/hb6FwOO4WM34ehJUd0YgHiDOIH8
Subject: Re: [dnssd] multicast over wireless links
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com
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: <http://www.ietf.org/mail-archive/web/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: Thu, 24 Jul 2014 19:55:34 -0000

+1. Of course 802.15.4-based mesh networks have to cope with multicast 
traffic but its use should be carefully considered.

Robert

On 24/07/2014 7:43 PM, Ted Lemon wrote:
> On Jul 24, 2014, at 2:33 PM, Robert Cragie <robert.cragie@gridmerge.com> wrote:
>> But as Alf said earlier, there are other wireless technologies which are not well suited to IP multicast traffic. 802.15.4-based mesh networks are a very good example and there is certainly a use case for DNS-SD in these type of networks.
> Broadcast is a good idea when the information being distributed is needed by all receivers, and when receivers' connections are persistent.   But newcomers to the network don't have the information until the next broadcast, or have incomplete information until the next broadcast, or have to trigger a new broadcast.
>
> In practice, in my experience, what this means is that multicast winds up producing much more traffic than would a non-multicast solution.   So that's why I suggest that it's better to rely heavily on multicast only in environments where multicast really is cheaper than unicast.
>
> (Of course, clearly DNSSD will use multicast to some extent; the question is how much.)
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>