Re: [DNSOP] review of USC/ISI Technical Report ISI-TR-693, June 2014 (as referenced by draft-ietf-dnsop-5966bis-01)

John Heidemann <johnh@isi.edu> Sat, 21 March 2015 00:58 UTC

Return-Path: <johnh@isi.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693861A0104 for <dnsop@ietfa.amsl.com>; Fri, 20 Mar 2015 17:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.51
X-Spam-Level:
X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 MRaNwz8KrUZv for <dnsop@ietfa.amsl.com>; Fri, 20 Mar 2015 17:58:39 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90431A0154 for <dnsop@ietf.org>; Fri, 20 Mar 2015 17:58:39 -0700 (PDT)
Received: from dash.isi.edu (vir.isi.edu [128.9.160.91]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t2L0w9Lg002337; Fri, 20 Mar 2015 17:58:09 -0700 (PDT)
Received: from dash.isi.edu (localhost.isi.edu [127.0.0.1]) by dash.isi.edu (Postfix) with ESMTP id 56373280DF3; Fri, 20 Mar 2015 17:58:09 -0700 (PDT)
From: John Heidemann <johnh@isi.edu>
To: Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>
In-reply-to: <55091D3E.2090608@redbarn.org>
References: <55091D3E.2090608@redbarn.org>
X-url: http://www.isi.edu/~johnh/
MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Date: Fri, 20 Mar 2015 17:58:09 -0700
Message-ID: <27569.1426899489@dash.isi.edu>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: johnh@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/_-EKl0f8HB_-J46V1z4Sim5gbWE>
Subject: Re: [DNSOP] review of USC/ISI Technical Report ISI-TR-693, June 2014 (as referenced by draft-ietf-dnsop-5966bis-01)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Mar 2015 00:58:41 -0000

On Tue, 17 Mar 2015 23:37:50 -0700, Paul Vixie wrote: 
>in draft-ietf-dnsop-5966bis-01, about which, more separately, this text
>appears:
>
>There are several advantages and disadvantages to the increased use
>of TCP as well as implementation details that need to be considered.
>This document addresses these issues and therefore extends the
>content of [RFC5966], with additional considerations and lessons
>learned from new research and implementations
>[Connection-Oriented-DNS].
>
>
>the [Connection-Oriented-DNS] paper (USC/ISI Technical Report
>ISI-TR-693, http://www.isi.edu/publications/trpublic/files/tr-693.pdf)
>is controversial and should not be used as the basis for standards work.
>examples of this technical report's failings include those shown below:


TL;DR: [Connection-Oriented-DNS] provides implementation choices and
performance guidance that apply directly to draft-ietf-dnsop-5966bis-01.
To remove it weakness the i-d by ignoring this research.  To imply that
"controversy", largely over deployment issues, invalidates what it says
about implementation and performance choices is inaccurate.



The longer version:


The i-d is giving guidance (informational) to how one should best do
DNS-over-TCP.

The i-d says:

	This document addresses these issues and therefore extends the
	content of [RFC5966], with additional considerations and lessons
	learned from new research and implementations
	[Connection-Oriented-DNS].

[Connection-Oriented-DNS] is relevant to the i-d to the extent that it
is an example of "research and implementation that provides additional
considerations and lessons" about use of TCP for DNS.

[Connection-Oriented-DNS] needs to provide implementation guidance about DNS over
TCP to apply to the i-d.


When I read over your detailed criticism of [Connection-Oriented-DNS],
they say a lot about deployment issues.  Fine, you're on the record as
opposing DNS over TCP with new signaling.  Let's assume, for the
moment, that [Connection-Oriented-DNS] gets deployment issues all wrong.
(I disagree, but let's take that off the table for the moment.)


Does the [Connection-Oriented-DNS] provide ANY OTHER guidance that is
relevant to "lessons learned about research and implementation" of
DNS-over-TCP?

I think it does:  It has two core points:

(1) to provide performance numbers of what one can expect from
DNS-over-TCP. It backs those up with testbed experiments, trace
analysis, simulation, and modeling.
(Like: what connection reuse rates should we expect, how much memory
will we need.)

And (2) it also has very specific suggestions on implementation choices
about how to get best possible performance out of DNS-over-TCP.
(Like: is newly standardized TCP fast open worth the effort?)

Both of those points seem DIRECTLY RELEVANT to this i-d.


To pretend that [Connection-Oriented-DNS] doesn't exist, because it is
"controversial", seems to do a disservice to the community.

In fact, to label the whole of [Connection-Oriented-DNS] as
"controversial" seems quite misleading.  We've been back and forth
several times about deployment issues, at least once on this list.
Perhaps the mechanisms for deployment and transition are controversial,
but deployment is 1/2 page of the body of the technical report.  If
that's all you see in it, well, I encourage you to look at the other
parts of the first 14 pages.



As for the specific comments about [Connection-Oriented-DNS]:  I'll let
the WG chairs comment if they think that's a good use of the WG's time.
Frankly, some of these comments seem quite nitpicky.  The first two
comments are about our experiments or design or work, but about our
description of two other people's work.  That's pretty meta.

However, you have an important point about deployment and
transition: can we run DNS over TCP on port 53 (as per the
specifications, although not as per common practice), or not?

That's a GREAT discussion for the WG.  Let's have that discussion.
You and I may or may not reach consensus on that topic, but the WG may.

But that's not the primary point of [Connection-Oriented-DNS].  That's
1/2 of the first 14 pages.

I humbly suggest that the performance and
implementation suggestions (those other 13.5 pages) may be useful to the
WG.

In fact, some of the performance results are useful across MANY
deployment choices that are connection-based.
DNS-over-HTTP will see similar connection reuse rates as
DNS-over-TCP.  TCP fastopen is good for HTTP and HTTP2 and DNS over TCP
and DNS over HTTP.

Please don't throw these babies out with the deployment bathwater.


   -John Heidemann