- From: Erik Nygren <erik@nygren.org>
- Date: Tue, 8 Jul 2014 21:24:05 -0400
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
- Message-ID: <CAKC-DJheNqpCzy46-sDf0ej6YP4eYWUx+MEwuxurZwsFBtjwdQ@mail.gmail.com>
Yes, this is single blocking lookup for browsing, although it can be done opportunistically in parallel with the A/AAAA lookups. Depending on TTL settings and how the records are handled relative to additional records, it's possible that the impact will be quite minimal. It would also be reasonable for a client to only wait a bounded amount of time after an A/AAAA response before using that, similar to how Chromium bounds how long it waits for an AAAA after it gets an A response. I'd read that SRV record thread which influenced some aspects of the design --- in particular, to have a single record that can vector off and provide information about other records that are needed and when they are needed, as well as to provide other hints (eg, that a DANE/TLSA record is available). There may be cases where doing this lookup serially could actually improve performance: * For example, with TLS 1.3 and handshake encryption, it could potentially even save TCP round-trip while being cacheable in resolvers. * If it can allow immediate negotiation to alpn=h2 for http scheme then that also improves overall performance. * If it allows clients supporting TLS SNI to be assigned to servers closer to them than more central servers with IPv4 VIPs per cert, that also improves overall performance. * If it allows signalling that clients must use HTTPS (ie, HSTS-style) in the same record, that also saves multiple TCP round-trips. In other words, I think it's worth exploring and looking at different scenarios before ruling it out-of-hand purely for latency reasons if there are enough values gained. Erik On Tue, Jul 8, 2014 at 8:53 PM, William Chan (陈智昌) <willchan@chromium.org> wrote: > Sorry, I only skimmed this and I didn't find it anywhere. Is this a > blocking lookup for browsing? If so, the current Chromium stance is likely > "no". If a parallel lookup, then there are complications and we'd have to > evaluate more closely. More details and history of our stance on SRV > records: https://code.google.com/p/chromium/issues/detail?id=22423. > > Cheers. > > > On Tue, Jul 8, 2014 at 7:36 AM, Erik Nygren <erik@nygren.org> wrote: > >> Following some discussion in both the TLS and HTTPBIS working groups at >> past meetings, it became clear that there was a need for a mechanism more >> flexible and powerful than SRV records. In particular, we've discussed the >> desire for an (optional) DNS-based mechanism for upgrading to HTTP/2 >> in-addition to AltSvc, especially for "http" scheme. >> >> One of the major browser concerns is limiting the number of DNS lookups >> that need to be performed before establishing a connection, especially when >> multiple records that may only exist a small fraction of the time need to >> be hunted for. This proposal attempts to limit that while also enabling >> future flexibility. There are some related problems in the TLS wg that >> this also provides a path to address. Regarding the concern that the >> adoption rate for new record types is slow, this is explicitly an >> additional mechanism for now (such that clients should fall back to A/AAAA >> address records and such when unavailable). >> >> Feedback is most welcome and I'm happy to discuss more in Toronto. This >> does not yet have a working group home yet, especially as it spans the >> interests of a number of WGs. There are also plenty of open issues, and >> I'd like to land on the concepts before getting into final details of >> encoding: >> >> http://tools.ietf.org/html/draft-nygren-service-bindings-00 >> >> >> >> ---------- Forwarded message ---------- >> From: <internet-drafts@ietf.org> >> Date: Fri, Jul 4, 2014 at 12:39 AM >> Subject: I-D Action: draft-nygren-service-bindings-00.txt >> To: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Service Binding DNS Records (DNS B) >> Author : Erik Nygren >> Filename : draft-nygren-service-bindings-00.txt >> Pages : 16 >> Date : 2014-07-03 >> >> Abstract: >> This document describes a DNS "B" RR which binds together information >> needed to establish connection to a service across multiple protocol >> layers, including the location of the server, the application-level >> protocol, and security bootstrap information. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-nygren-service-bindings/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-nygren-service-bindings-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft >> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft> >> directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >
Received on Wednesday, 9 July 2014 01:24:32 UTC