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

Måns Nilsson <> Sat, 03 January 2015 14:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D8CD1A874A for <>; Sat, 3 Jan 2015 06:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 40HgSa47lOh9 for <>; Sat, 3 Jan 2015 06:32:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B7C351A873D for <>; Sat, 3 Jan 2015 06:32:30 -0800 (PST)
Received: by (Postfix, from userid 1004) id 123AB9CEF; Sat, 3 Jan 2015 15:32:29 +0100 (CET)
Date: Sat, 3 Jan 2015 15:32:29 +0100
From: =?utf-8?B?TcOlbnM=?= Nilsson <>
To: Eliot Lear <>
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZwgA9U+XZDXt4+m+"
Content-Disposition: inline
In-Reply-To: <>
X-Purpose: More of everything NOW!
X-happyness: Life is good.
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Delan Azabani <>,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Jan 2015 14:32:33 -0000

Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard Date: Sat, Jan 03, 2015 at 01:09:32PM +0100 Quoting Eliot Lear (
> 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.  

Getting bad results as described above requires breaking a number
of established operations practices. 
Simply keeping SRV and target AAAA/A records in the same zone or at least
in the set of zones served by the same name server(s) will let the name
server send a SRV reply and bundle the host records as Additional Data.

Besides, caching. It is here, and given the herd behaviour pattern of the 
user population it is likely that all popular (ie. loadwise relevant)
records show up in warm caches in all major resolver farms.

And just look at the CNAME chaining going on in various steamy server
farms. That it works and with speed is as close to wonder as I'd like
to go in a scientific setting ;-)

> 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.

That things might not work right now and that current implementations have
issues with suboptimal configuration have not stopped people from using,
developing and refining more farsighted resource location systems before.
There are known issues that make the specification of a new HTTP protocol 
version important; one of which is the reliance on singular hosts in the
service location part. The urgency is felt, but the addition of a proven
record system for redundance and load balance should , while adding some
delay, pay back in terms of operational gains, and then some.

I strongly support incorporating SRV record support in the HTTPbis 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
You mean you don't want to watch WRESTLING from ATLANTA?