Re: [dnssd] multicast over wireless links

Robert Cragie <robert.cragie@gridmerge.com> Thu, 24 July 2014 18:33 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 5E3691B27EC for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 11:33:45 -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 AnTKj9pEWIoO for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 11:33:40 -0700 (PDT)
Received: from mailscan1.extendcp.co.uk (mailscan20.extendcp.co.uk [176.32.226.66]) (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 B5EC51A0194 for <dnssd@ietf.org>; Thu, 24 Jul 2014 11:33:40 -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 1XANpj-0003Ht-4i for dnssd@ietf.org; Thu, 24 Jul 2014 19:33:39 +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 1XANpg-0000rS-Et for dnssd@ietf.org; Thu, 24 Jul 2014 19:33:39 +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 1XANpg-0002pw-1q for dnssd@ietf.org; Thu, 24 Jul 2014 19:33:36 +0100
Message-ID: <53D15182.1040307@gridmerge.com>
Date: Thu, 24 Jul 2014 19:33:38 +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>
In-Reply-To: <421C934C-F0CB-4FBF-83ED-04A48526D5F2@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms050100040905090000050503"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/neX7E43B2WkrpTVy3mc8DDWeO80
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 18:33:45 -0000

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.

Robert

On 24/07/2014 7:23 PM, RJ Atkinson wrote:
> Ted,
>
>    When IP multicasting originated, wired Ethernet was a shared
> medium using CSMA/CD.  A single IP/Ethernet frame would reach
> all nodes on that IP subnet.  I still remember vampire taps
> and the big yellow Coax cable in my office from back then.
>
>    In the 1990s, switched Ethernet became commonplace and
> (as deployed) the wire to the desktop was not a shared
> medium, but instead was a solo link back to the Ethernet
> switch.  This meant that the IP/Ethernet frame did not
> automatically get seen by all nodes on that Ethernet
> (bridged) link.  The IETF didn't drop IP multicasting,
> or discourage use of IP multicasting.  Instead, Ethernet
> switch vendors made various optimisations inside their
> Ethernet switch products (e.g. IGMP snooping) to make
> IP multicasting work well over wired switched Ethernet.
> IETF folks were involved in helping the Ethernet vendors
> understand some implementation options for those optimisations
> in those Ethernet products.
>
>    The situation today with 802.11 is entirely analogous
> to that previous situation with wired Ethernet moving
> from shared CSMA/CD to switched dedicated links, and the
> IETF community should have the same response -- don't drop
> the use of IP multicasting, don't discourage use of
> IP multicasting -- instead engage with others so that a
> link-specific optimisation can be put into use only for
> -- and only within -- those link-specific vendor devices
> (e.g., wireless access point, 802.11 radio, or whatever
> term one prefers).
>
> Yours,
>
> Ran
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>