ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

2015-01-03 06:10:16
Hi Delan,

We have had a fair amount of discussions about this, and I would say
that perhaps very few people would disagree with what you wrote below. 
However, an additional level of indirection in the SRV record can come
at a cost, which is additional latency, and perhaps a lot of additional
latency on first use, and it depends on a lot of factors, like RR TTLs
on both the SRV record itself and the A record that is returned as part
of RDATA, and whether or not that record itself requires multiple
queries to satisfy.  And so we examined not one, but several new
different RRs to address those concerns, but in the end, people want to
get on with getting out the door what is in the document now.

Eliot

On 1/2/15 9:29 AM, Delan Azabani wrote:
I'm not sure if it's appropriate for a random netizen like myself to
contribute to these comments, so my apologies in advance if it isn't.

Please consider supporting SRV resource records.

HTTP is simultaneously important enough that one can't simply run a
single server for any popular application, but not so important that it
deserves to necessarily be the A/AAAA record for every hostname.

SRV makes service discovery more flexible than even MX records by:

  * Decoupling the default use of TCP port 80 for HTTP, allowing hosts
    to run multiple distinct HTTP servers without needing a reverse
    proxy or requiring users to explicitly override the port;

  * Allowing server administrators to create a tiered and weighted form
    of load balancing by using the record's Priority and Weight fields,
    again without shifting the point of failure to reverse proxies; and

  * Making it easier to transparently and scalably host services for
    multiple protocols on a single apex domain name.

Although the Target field of a SRV RR is a domain name, not an IPv6 or
IPv4 address, the resolution delay before a TCP connection is initiated
is unlikely to increase significantly because:

  * To reduce the need for multiple queries, "Implementors are urged,
    but not required, to return the address record(s) in the Additional
    Data section." [RFC 2782 page 4]

  * Like the record types PTR, MX and CNAME, "Domain names in RRs which
    point at another name should always point at the primary name and
    not the alias. This avoids extra indirections in accessing
    information." [RFC 1034 § 3.6.2]

To further avoid the complexity and inefficiency of multiple queries,
'only the service name "http" should be used' when SRV records are
used, not the synonyms "www" or "www-http". [RFC 6335 § 5]

LDAP, SIP, XMPP and Kerberos are successful examples of protocols which
rely on SRV resource records for service discovery.

For these benefits to be realised however, HTTP/2 should explicitly opt
into support for SRV records, because "Service SRV records SHOULD NOT
be used in the absence of" an indication in the protocol specification
that clients should use SRV records for discovery. [RFC 2782 page 2]





Attachment: signature.asc
Description: OpenPGP digital signature

<Prev in Thread] Current Thread [Next in Thread>