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

Mark Andrews <> Sat, 03 January 2015 21:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E0D1F1A0470 for <>; Sat, 3 Jan 2015 13:19:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.611
X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2uyuuVEeYYXY for <>; Sat, 3 Jan 2015 13:18:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00F021A0248 for <>; Sat, 3 Jan 2015 13:18:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1E05B1FCAC3; Sat, 3 Jan 2015 21:18:55 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id DE186160066; Sat, 3 Jan 2015 21:25:06 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTPSA id 364CD16005B; Sat, 3 Jan 2015 21:25:06 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 128BA26FFE05; Sun, 4 Jan 2015 08:18:47 +1100 (EST)
To: =?utf-8?B?TcOlbnM=?= Nilsson <>
From: Mark Andrews <>
References: <> <> <>
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
In-reply-to: Your message of "Sat, 03 Jan 2015 15:32:29 +0100." <>
Date: Sun, 04 Jan 2015 08:18:46 +1100
Message-Id: <>
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 21:19:01 -0000

In message <>rg>, =?utf-8?B?TcOlbnM=?= Nils
son writes:
> 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.

Or we could add a EDNS flag/option which tells the recursive server
to fetch the SRV targets *before* returning the response.  This
could also say follow CNAME chains of the target if they happen to
exist.  You then get the same performance as a CNAME chain with a
A/AAAA lookup.

The only difference between SRV and CNAME is which entity triggers
the additional lookups.  The client or the recursive server.

The SRV client can set the option / flag (both of which are supposed
to be ignored if not understood).  As the recursive server population
implements the option / flag performance will increase when the
record in not already in the cache.  The SRV client still falls
back to direct A/AAAA lookups if there isn't a record for the SRV
target in the additional section.

> 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 ;-)

It all depends on caching.

> > 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
> specification.
> --
> MÃ¥ns Nilsson     primary/secondary/besserwisser/machina
> MN-1334-RIPE                             +46 705 989668
> You mean you don't want to watch WRESTLING from ATLANTA?

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: