IETF Logo Mail Archive

Re: [dnssd] multicast over wireless links

Ted Lemon <ted.lemon@nominum.com> Thu, 24 July 2014 17:26 UTC

Return-Path: <Ted.Lemon@nominum.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 07F871A0AD5 for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 10:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 B4_njaf6a7b1 for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 10:26:19 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16E51A0AF5 for <dnssd@ietf.org>; Thu, 24 Jul 2014 10:25:14 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6B52AF805A for <dnssd@ietf.org>; Thu, 24 Jul 2014 10:25:14 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 65028190052; Thu, 24 Jul 2014 10:25:14 -0700 (PDT)
Received: from nat64.meeting.ietf.org (31.130.238.127) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 10:25:14 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <1F1E6B22-5FF2-41DF-BA86-20A9D57E74CC@gmail.com>
Date: Thu, 24 Jul 2014 13:25:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <7414908D-B2A9-4935-912F-EF3E4995065F@nominum.com>
References: <331F9173-DB56-4D9A-B09F-956FF6D8DA2B@gmail.com> <DBA73077-1A9F-4E5E-89C7-AF80544F7235@nominum.com> <1F1E6B22-5FF2-41DF-BA86-20A9D57E74CC@gmail.com>
To: RJ Atkinson <rja.lists@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [31.130.238.127]
Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/lQaHxPbsdTrXKB-twFCr9Q-XvII
Cc: dnssd@ietf.org
Subject: Re: [dnssd] multicast over wireless links
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.15
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: <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 17:26:21 -0000

On Jul 24, 2014, at 12:22 PM, RJ Atkinson <rja.lists@gmail.com> wrote:
> IP/SATCOM is commonly used today within a single
> administrative domain to connect different sites
> together.

Forgive me, but this doesn't sound like a valid use case for DNSSD.   It sounds like you are trying to use DNSSD to solve a problem that is actually out of scope, because you are attracted to the benefits that a multicast DNSSD solution would provide (which I agree exist).

But I think that this is a very specialized use case, and that the WiFi use case is a _much_ more important use case.   Asking IEEE to fix WiFi is not really a good approach to addressing the problem of inefficient multicast for existing deployments, and this work is intended to address existing deployments.

Therefore, I think that if we want to address this use case, the right way to do it is to come up with a mechanism for doing multicast distribution of DNSSD updates on broadcast-friendly networks, and not to just make this the default operational mode for DNSSD.

v2.23.0 | Report a Bug | By Email