Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00

Tom Pusateri <pusateri@bangj.com> Thu, 24 July 2014 20:21 UTC

Return-Path: <pusateri@bangj.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 DBAFA1B27D7 for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 13:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.038
X-Spam-Level:
X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 PrLl22Oi9XND for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 13:21:20 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB33A1B2802 for <dnssd@ietf.org>; Thu, 24 Jul 2014 13:21:15 -0700 (PDT)
Received: from dhcp-a545.meeting.ietf.org (dhcp-a545.meeting.ietf.org [31.133.165.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 2273A1348D; Thu, 24 Jul 2014 16:21:16 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <4ADFCA4A44B18946883BA96F64773E0150E2CF31@NASANEXD02B.na.qualcomm.com>
Date: Thu, 24 Jul 2014 16:21:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8242FDC4-4763-47B5-A205-E41C23A0367B@bangj.com>
References: <D974B48F-6906-4FA4-B410-BB1BF364E964@bangj.com> <4ADFCA4A44B18946883BA96F64773E0150E2CF31@NASANEXD02B.na.qualcomm.com>
To: "Aggarwal, Ashutosh" <aaggarwa@qce.qualcomm.com>
X-Mailer: Apple Mail (2.1971.5)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/K4bPQMJ9jVyAS8-8BtyrUFFdORo
Cc: "dnssd@ietf.org" <dnssd@ietf.org>, "Dave Thaler (dthaler@microsoft.com)" <dthaler@microsoft.com>
Subject: Re: [dnssd] draft-aggarwal-dnssd-optimize-query-00
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 20:21:23 -0000

> On Jul 24, 2014, at 2:58 PM, Aggarwal, Ashutosh <aaggarwa@qce.qualcomm.com> wrote:
> 
> Thanks for your comments. Please see below:
> 
> -----Original Message-----
> From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Tom Pusateri
> Sent: Thursday, July 24, 2014 11:10 AM
> To: dnssd@ietf.org
> Subject: [dnssd] draft-aggarwal-dnssd-optimize-query-00
> 
> Ashutosh,
> 	Interesting draft. I have a few comments.
> 
> 1. In section 3, you describe the TXT record filters in the additional section. But you don't exactly specify what is in the query section. Does this apply only for queries to instances of TXT records or does this also apply to PTR queries for instances of services or for PTR queries for just the service itself or all three?
> 
> [Aggarwal, Ashutosh] 
> This contribution was written to optimize the DNS-SD query scenario when the client application issues the PTR query with the service name. The contribution proposes to add DNS TXT records for such queries. 
> 

Ok, but a TXT record is for an instance of a service. So your proposal is now changing what is expected in a TXT record.

Let's clarify to be sure. You are suggesting this:

----------------------------------------
Query Section:

_printer._tcp.local. IN PTR

Additional Records Section:

_printer._tcp.local. IN TXT "color=True"
----------------------------------------

An mDNS participant that isn't aware of your draft, would expect the TXT record in the AR Section to be an actual instance of a service. Something like this would be more expected:

HP OfficeJet._printer._tcp.local. IN TXT "color=True"

and the recipient wouldn't know what to do with

_printer._tcp.local. IN TXT "color=True"

since it is not an instance of a service.


Thanks,
Tom

> 2. There would seem to be a tradeoff in requesting too much or too little. If you apply TXT filters and then don't get any responses, you will have to query again with a broader filter. The optimal case will depend on the service you're looking for. In some cases you would have been better off without the filter. In other cases, knowing there is no match is useful too. Each application will have to make that tradeoff when it queries.
> [Aggarwal, Ashutosh] 
> You are absolutely correct regarding trade-offs. The pre-condition is that the client application knows what constraints or filters it is looking to apply and it should specify them in the initial query. It would be better than querying for the service name and then establishing a connection with each service instance for subsequent negotiation. If the client application doesn't need to apply any filter, it can send the query with the service name only. The decision regarding which keys/filters to apply is application specific as you mention. Just like DNS-SD has the provision for the responder to add key/value pairs in the DNS response message, the contribution proposes to enable the use of DNS TXT records in the PTR queries for the service name.
> 
> 3. With your implied logical operations of TXT attribute filters, things could get confusing when there are multiple records queried at once. You should expand on section 3 to explain this after clarifying from question #1 which record types are in the query section. It's perfectly legal to query the PTR record for _printer._tcp.local and the TXT and SRV records for HP OfficeJet._printer._tcp.local in the same query. Will the TXT record in the additional records section have to be for an instance like HP OfficeJet._printer._tcp.local or does it apply to the PTR query for _printer._tcp.local? If the TXT record can be for a service and not a specific instance, this changes who responds.
> When there are multiple TXT records in the additional section, it gets more confusing on how to apply the logical operations.
> 
> [Aggarwal, Ashutosh] 
> [Aggarwal, Ashutosh] 
> I added multiple TXT records details if we want to allow for complex filter criteria. I can add some examples to clarify for sure. We can discuss if we can summarize the desired filter criteria using a single TXT record. The filtering scheme was proposed for PTR query with the service name.
> 
> Hope this answers your comments,
> Ashutosh
> 
> 
> Thanks,
> Tom
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd