Re: [Doh] [Ext] DNS Camel thoughts: TC and message size
Patrick McManus <pmcmanus@mozilla.com> Sun, 10 June 2018 23:10 UTC
Return-Path: <pmcmanus@mozilla.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37970130F28 for <doh@ietfa.amsl.com>; Sun, 10 Jun 2018 16:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 MpCuECD4f-CA for <doh@ietfa.amsl.com>; Sun, 10 Jun 2018 16:10:21 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 580C8130EDE for <doh@ietf.org>; Sun, 10 Jun 2018 16:10:21 -0700 (PDT)
Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id 271F83A019 for <doh@ietf.org>; Sun, 10 Jun 2018 19:10:20 -0400 (EDT)
Received: by mail-oi0-f41.google.com with SMTP id 188-v6so2952871oid.12 for <doh@ietf.org>; Sun, 10 Jun 2018 16:10:20 -0700 (PDT)
X-Gm-Message-State: APt69E02JWPASgK9b+t/3hHStobuH1JHN53h1mLxCTtszv2uCSO2e2WN MFBbzHixG+v34XzzFfgnAP3AhALi0La7TMmHm+0=
X-Google-Smtp-Source: ADUXVKJ3eatE/OiqnqQsgFKWdZTLxoWfdO4ILPXNlmGnwQm+hV9oKTvCWmBS4IwGV2TyE8ibOr8WbuF91rmoJLWikhw=
X-Received: by 2002:aca:a88b:: with SMTP id r133-v6mr7784355oie.213.1528672219842; Sun, 10 Jun 2018 16:10:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 16:10:18 -0700 (PDT)
In-Reply-To: <20180610161645.GF8515@mx4.yitter.info>
References: <CAOdDvNriZDjU9yqUQjqN4fO84ENPWO3si-QePiKRgt+7VJVK0g@mail.gmail.com> <23321.27027.73356.94056@gro.dd.org> <CAOdDvNr=kLHPCtCHRx4=rpA1oDogQqdAJ0nR156BWABiFP_bzA@mail.gmail.com> <20180607215851.GA32738@server.ds9a.nl> <CAOdDvNqNpZ8fKPCO5sEqjROBHjg4wx-GGPMYSSynode10jeC0Q@mail.gmail.com> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <CAN6NTqxA4PcrtS_3umwGERLt9WPoX4p0a0u8pL-O2=CKKTBfyA@mail.gmail.com> <23322.62892.251560.128565@gro.dd.org> <20180608221700.GC8515@mx4.yitter.info> <23323.5488.915402.337488@gro.dd.org> <20180610161645.GF8515@mx4.yitter.info>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Sun, 10 Jun 2018 19:10:18 -0400
X-Gmail-Original-Message-ID: <CAOdDvNrj20OVysaQHMczeMaiDhup4f5B=2n0xxQWmtTtm-OROA@mail.gmail.com>
Message-ID: <CAOdDvNrj20OVysaQHMczeMaiDhup4f5B=2n0xxQWmtTtm-OROA@mail.gmail.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a45137056e51bc6f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/_eEjUyZzX06HfefEobN4EAXD-aQ>
Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jun 2018 23:10:24 -0000
On Sun, Jun 10, 2018 at 12:16 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote: > > I think if we can come up with the right words, then it'll make things > less risky, but I also worry about the deployment story unless we can > figure out what to do if something in the pipeline can't take the > "jumbo" messages. > > After having re-read the related threads, I think it might be helpful to talk about how content negotiation works in the http pipeline. let's assume we have 2 message formats - wireformat-64 and traditional wireformat. And that we define traditional wireformat to be limited to 16 bits (its not clear to me whether or not that is really true in practice, but let's say we determine that it is.). I believe the concern is "traditional -> doh -> doh" where the doh -> doh link could use wireformat-64 and then the initial traditional client cannot consume wireformat-64 but ends up with it anyhow. Is that right? That shouldn't happen. The middle node realizes it is a gateway for a traditional client and only indicates to the final server that it knows how to speak traditional wireformat for the request it is making. The fact that it is over DoH does not add new media types to the request by default, the middle node needs to (essentially) opt-in to that via the Accept: request header and it wouldn't do that here. making the middle node a doh http cache makes things a little more complicated for the cache, but not in a way that is unusual for an http cache. If in that scenario it had previously done a transaction for a doh client that supported wireformat-64 it could certainly cache that (modulo all the other caching rules) and then when the traditional client came along, the cache just needs to recognize that the variant it has in cache is not one that the client recognizes. At which point it makes a new upstream request for traditional-wireformat-only. This works ok even if there is a non-doh aware http cache in the chain as long as the server marks the response "Vary: Accept" (which it should do if it creates different variants based on the accept header.. that's not something DoH needs to specify, 723x has it covered - pure http behavior). So if traditional wireformat consumers are limited to 16 bit sizes we definitely should document that as part of the wireformat definition. The next question is are they, or are we just at a point where we are concerned they might be? I'm really not sure on that one. in either case, I don't see a reason to restrict protocol beyond the wireformat definition.
- Re: [Doh] Are we missing an architecture? (was Re… Patrick McManus
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Puneet Sood
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Ted Lemon
- Re: [Doh] [Ext] Are we missing an architecture? (… Ted Lemon
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Ted Lemon
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Mateusz Jończyk
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Sara Dickinson
- Re: [Doh] [Ext] Are we missing an architecture? (… Daniel Stenberg
- Re: [Doh] [Ext] Are we missing an architecture? (… Sara Dickinson
- Re: [Doh] [Ext] Are we missing an architecture? (… Daniel Stenberg
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Ray Bellis
- Re: [Doh] [Ext] Are we missing an architecture? (… Patrick McManus
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Ben Schwartz
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Mukund Sivaraman
- Re: [Doh] [Ext] Are we missing an architecture? (… Ben Schwartz
- Re: [Doh] [Ext] Are we missing an architecture? (… Petr Špaček
- Re: [Doh] [Ext] Are we missing an architecture? (… Ray Bellis
- Re: [Doh] [Ext] Are we missing an architecture? (… bert hubert
- Re: [Doh] [Ext] Are we missing an architecture? (… Ray Bellis
- Re: [Doh] [Ext] Are we missing an architecture? (… Dave Lawrence
- Re: [Doh] [Ext] Are we missing an architecture? (… Dave Lawrence
- Re: [Doh] [Ext] Are we missing an architecture? (… Paul Hoffman
- Re: [Doh] [Ext] Are we missing an architecture? (… Tom Pusateri
- [Doh] DNS Camel thoughts: TC and message size bert hubert
- Re: [Doh] DNS Camel thoughts: TC and message size Petr Špaček
- Re: [Doh] DNS Camel thoughts: TC and message size Tony Finch
- Re: [Doh] DNS Camel thoughts: TC and message size Hewitt, Rory
- Re: [Doh] DNS Camel thoughts: TC and message size Benno Overeinder
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… George Michaelson
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Paul Hoffman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Tony Finch
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… bert hubert
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Paul Hoffman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Martin J. Dürst
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Paul Hoffman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Tony Finch
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Ray Bellis
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Ray Bellis
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… bert hubert
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Robert Edmonds
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Mateusz Jończyk
- [Doh] AXFR as several messages Re: [Ext] DNS Came… bert hubert
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… John Dickinson
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Ray Bellis
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Mukund Sivaraman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Mukund Sivaraman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Tony Finch
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Martin Thomson
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Mark Nottingham
- [Doh] DNS Camel thoughts: TC and message size Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Ólafur Guðmundsson
- [Doh] Are we missing an architecture? (was Re: DN… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… bert hubert
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] Are we missing an architecture? (was Re… Mark Nottingham
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Mukund Sivaraman
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] Are we missing an architecture? (was Re… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Andrew Sullivan
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Patrick McManus
- Re: [Doh] [Ext] DNS Camel thoughts: TC and messag… Dave Lawrence
- Re: [Doh] Are we missing an architecture? (was Re… Dave Lawrence
- Re: [Doh] Are we missing an architecture? (was Re… bert hubert
- Re: [Doh] Are we missing an architecture? (was Re… Dave Lawrence
- Re: [Doh] [Ext] Are we missing an architecture? (… Ray Bellis