Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

Marek Vavruša <mvavrusa@cloudflare.com> Tue, 12 July 2016 03:26 UTC

Return-Path: <mvavrusa@cloudflare.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9917112D0D9 for <dnsop@ietfa.amsl.com>; Mon, 11 Jul 2016 20:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
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 IfNtcKIkFU5A for <dnsop@ietfa.amsl.com>; Mon, 11 Jul 2016 20:26:01 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F97912D0D3 for <dnsop@ietf.org>; Mon, 11 Jul 2016 20:26:01 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id j17so3110593ywg.0 for <dnsop@ietf.org>; Mon, 11 Jul 2016 20:26:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OSF1Eyke52plhwYEyO6WZAYPBjq/lrT6UHRVocLysMU=; b=OWfgMj2PbSP3cSaeJu0wxkfy6yO9WBQH/A0ELW1iaShF2IDvQlfbTTjwcOtEO9rZWd 64gTQQvhq17sJRR40TGxaABDrMXqwzu3hS59bEQkfaucgewiWdJEWe21a9ePuP6WQkFp yemRZYE4G1um9BVOeYQKhEdMeuCTr3ex9V+u4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OSF1Eyke52plhwYEyO6WZAYPBjq/lrT6UHRVocLysMU=; b=Zl5nx7sAQvpnjqsHOjcjhu9tdiE3BmG3z6tM15UgLnW+LLAbEISxeeZLKDJv4XWtHa BGUrzZC+cHGbDr+1E1kru7HgT95XQhsJg7Dhinlgv5fb6krS83NsTIBtaYUWZPreMHX8 pA1hUKrKc7LH617poLfS8dgLc4AR5wguCsjIO+Y6boUdp8tixmEIBkKpxxV1pcPEkPWk 5gbgsy685W62Sh9ZMUrIhmtRT2sFxtKNkO1igJt8PX0YS8/+D3e1zmBr0mLfsPv3zoSB qhqPOPhW6wFNcLGHwwSfYiMVqlZHmppeifx/bE6iiOsH9P4GKhTz7OgkXY+/OaGUZoaq GM3g==
X-Gm-Message-State: ALyK8tLV3A+enxCqebof8Rb6wPtOCZcmAoI+wJQr3ZiwKCHiaEJ8rdqJC0mOdqbCIO5rES6yrUZbJy1/IdvC2l2G
X-Received: by 10.129.136.193 with SMTP id y184mr8067ywf.148.1468293960953; Mon, 11 Jul 2016 20:26:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.32.137 with HTTP; Mon, 11 Jul 2016 20:26:00 -0700 (PDT)
In-Reply-To: <20160712030624.29734.qmail@ary.lan>
References: <em4745d403-8957-4994-9819-47cc8d9e1364@bodybag> <20160712030624.29734.qmail@ary.lan>
From: Marek Vavruša <mvavrusa@cloudflare.com>
Date: Mon, 11 Jul 2016 22:26:00 -0500
Message-ID: <CAC=TB124b7G0w48LY4zP6TOqE+xZ3n1Fp4_KMaUTB_ZtCtrzCw@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/utAlPU4pkroUPZfFARJVUSHqybQ>
Cc: adrien@qbik.com, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 12 Jul 2016 03:26:03 -0000

On Mon, Jul 11, 2016 at 10:06 PM, John Levine <johnl@taugh.com> wrote:
>>So I suggest some thought should be given to reducing round-trips by
>>allowing for multiple DNS request payloads in a single HTTP request
>>message, and multiple DNS response payloads in an HTTP response message.
>
> Don't you get this automatically if it's treated as a TCP DNS
> connection?  You stuff a bunch of requests down the pipe, and you get
> back a bunch of responses.
>
> See RFC 7766.
>
> R's
> John

You get queueing for free, but not pipelining and out-of-order
responses, that has to be defined.
The draft mentions this, but I think at this point it should just
depend on HTTP/2,
as it's the only way to get decent performance from resolvers but high
variance in response time,
and request semantics in both is different and needs to be defined,
i.e. what happens when client cancels
in-flight query, what happens when server resolver pushes response.

Marek


> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop