Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
Eliot Lear <lear@cisco.com> Sat, 03 January 2015 16:53 UTC
Return-Path: <lear@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75A31A1BDB for <ietf@ietfa.amsl.com>; Sat, 3 Jan 2015 08:53:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Level:
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 VXKQ4QlHrWTu for <ietf@ietfa.amsl.com>; Sat, 3 Jan 2015 08:53:55 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6921A901E for <ietf@ietf.org>; Sat, 3 Jan 2015 08:53:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5317; q=dns/txt; s=iport; t=1420304034; x=1421513634; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=B8QwSXrfNw5PlcpwrL26kjLosSeDr7SGOGWQn+M4jQ4=; b=QGojyTo9IjHChBMPHLa0KsRdyxK5XjRbhN6f0FXmwDoWTQP1J/65FnV6 zZZTuJTDgWTeR8TfaQSd0eNRHz669n5dYL7bVqo6+H/miLFFN9/Qg/prh Rp9tQralGRDMLBTkilfu75+RWHFg87FB6QEfjzWMMyVz80llMxeMX/+zH k=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAEYeqFStJssW/2dsb2JhbABbg1hYgwXDN4VvAoEaAQEBAQF9hA0BAQQjVQEQCxgJFgQHAgIJAwIBAgFFBgEJAwEFAgEBFgGIEQ2pA5NvAQEBAQEBAQEBAQEBAQEBAQEBAQEBF48UYweCaIFBBY9ggSdNhTSBPYRHi0wigX01gT09MQGCQgEBAQ
X-IronPort-AV: E=Sophos;i="5.07,690,1413244800"; d="asc'?scan'208";a="293555285"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 03 Jan 2015 16:53:52 +0000
Received: from [10.61.167.63] ([10.61.167.63]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t03Grqf9013217; Sat, 3 Jan 2015 16:53:52 GMT
Message-ID: <54A81E9A.1020700@cisco.com>
Date: Sat, 03 Jan 2015 17:53:46 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Patrik Fältström <paf@frobbit.se>, Må ns Nilsson <mansaxel@besserwisser.org>
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
References: <CAK3LatFh3ZU8ACk8grzLA9oCv2qqUHttz2z83b66xKnfs78mRA@mail.gmail.com> <54A7DBFC.8010800@cisco.com> <20150103143226.GC13599@besserwisser.org> <89DB2965-68B1-43D0-BBEB-FF49DB666A6D@frobbit.se>
In-Reply-To: <89DB2965-68B1-43D0-BBEB-FF49DB666A6D@frobbit.se>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="1g93qLFAIXJR5N4m4DGPw9nACGutGnXeI"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/Zy3KFwbai7ZM0XB7A67G-y1oQ20
Cc: Delan Azabani <delan@azabani.com>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jan 2015 16:53:58 -0000
Hi Patrik, On 1/3/15 4:49 PM, Patrik Fältström wrote: >> On 3 jan 2015, at 15:32, Måns Nilsson <mansaxel@besserwisser.org> wrote: >> >> I strongly support incorporating SRV record support in the HTTPbis >> specification. > FWIW, I am also in favor or SRV, although I (being biased) think "how to use URI with HTTP2" would not be a bad addition either[1]. > > We do though have multiple discussions like these, that I do not think really conclude: > > <https://news.ycombinator.com/item?id=8404612> > > Because of this, what I think IS (at least) needed in the http2 spec are a few words about DNS. Else the discussions will just continue and continue... > > One could for example say something like: > > "If the URI does not include a path (only consists of scheme and authority, which in turn include domain), a client MIGHT look up either SRV record _http._tcp.domain or URI for the same owner_http._tcp.domain and act on the result of those lookups according to the SRV and URI spec respectively." > > And then reference some "happy eyeballs" specification on how to do it in detail. There there was a fuller discussion about this in the WG about two years ago, and then again last year. As John pointed out there are a few more issues, one of which is that the release philosophy taken by the WG is that there is some expectation that HTTP2 will not be the last version released, and some additions may come sooner than later. This presents several problems for SRV. First, as a matter of IANA policy we don't normally allocate more than one name for the same service, no matter the version. This is something of a sore point, and a general one at that. One would really like to be able to pass some initial protocol parameter information back as part of a DNS query such that the information could be reasonably cached (oh, say versioning?). I am not convinced that the WG has a full handle on this with the various header games being considered, but there was a fair bit of discussion about this as well a while back, and there are some tradeoffs to be made, like binding the information tightly to the connection and all of its attendant properties. Also, tying versioning of any form into the DNS where the different versions have different security properties makes the solution dependent on DNSSEC. I'm ALL for DNSSEC, but as there are alternatives that don't require it, it's not the draw we would like in this case. And no, you needn't preach to the choir on this point: it really SHOULD be a draw because it provides huge possibilities for doing all sorts of fun application initialization, but I digress. Second, even if we did handle versioning in SRV, there are known to be residential gateways out there that can't handle very many parallel DNS queries, and so we run into a loss problem. Finally, to address Måns' comments, additional data for the target doesn't get signed (but correct me if I missed a change). (Actually, one of things I wanted from DPRIVE was the ability to handle multiple questions in the same transaction, but alas, probably not.) In addition, with caching times down to small numbers of minutes for many sites (or less), we probably can't say that this is a simple 1st transaction cost. What's more many enterprises do a zone cut at _tcp.example.com, and it is not uncommon to see TCP connections for those transactions (I know at least one network administrator who thought it was unheard of *not* to do a zone cut and delegation at _tcp). To address a bunch of these issues I had posited a record [1] that actually made use of the same QNAME, but it really is quite (dare the author say overly?) complex. And this leads us back to performance. I personally do not have an answer for what acceptable performance is in these circumstances. And so some experimentation would really REALLY be good. Is 100 ms for this feature acceptable? 30? 80? 200? I really can't say, and there was no desire in the WG to go this far. I will say that Cisco has an open RFP for related work if any researchers want to take the challenge.[2] Eliot [1] http://tools.ietf.org/html/draft-lear-httpbis-svcinfo-rr [2] http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp13077.html
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Delan Azabani
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Eliot Lear
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … John C Klensin
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Måns Nilsson
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Patrik Fältström
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Eliot Lear
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Delan Azabani
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Mark Andrews
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Patrik Fältström
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Patrik Fältström
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Mark Andrews
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Måns Nilsson
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Patrik Fältström
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Eliot Lear
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Måns Nilsson
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Mark Andrews
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Eliot Lear
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Dave Cridland
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … James M Snell
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Poul-Henning Kamp
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Doug Barton
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Doug Barton
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Matthew Kerwin
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Greg Wilkins
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Chris Dailey
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Julian Reschke
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Martin Thomson
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Julian Reschke
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Constantine A. Murenin
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Constantine A. Murenin
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Cory Benfield
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Daniel Stenberg
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Amos Jeffries
- Re: Last Call: <draft-ietf-httpbis-http2-16.txt> … Willy Tarreau