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

Mark Andrews <marka@isc.org> Sat, 03 January 2015 21:19 UTC

Return-Path: <marka@isc.org>
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 E0D1F1A0470 for <ietf@ietfa.amsl.com>; Sat, 3 Jan 2015 13:19:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.611
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uyuuVEeYYXY for <ietf@ietfa.amsl.com>; Sat, 3 Jan 2015 13:18:59 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F021A0248 for <ietf@ietf.org>; Sat, 3 Jan 2015 13:18:58 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 1E05B1FCAC3; Sat, 3 Jan 2015 21:18:55 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DE186160066; Sat, 3 Jan 2015 21:25:06 +0000 (UTC)
Received: from rock.dv.isc.org (unknown [149.20.66.86]) by zmx1.isc.org (Postfix) with ESMTPSA id 364CD16005B; Sat, 3 Jan 2015 21:25:06 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 128BA26FFE05; Sun, 4 Jan 2015 08:18:47 +1100 (EST)
To: =?utf-8?B?TcOlbnM=?= Nilsson <mansaxel@besserwisser.org>
From: Mark Andrews <marka@isc.org>
References: <CAK3LatFh3ZU8ACk8grzLA9oCv2qqUHttz2z83b66xKnfs78mRA@mail.gmail.com> <54A7DBFC.8010800@cisco.com> <20150103143226.GC13599@besserwisser.org>
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." <20150103143226.GC13599@besserwisser.org>
Date: Sun, 04 Jan 2015 08:18:46 +1100
Message-Id: <20150103211847.128BA26FFE05@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/2HlH-BAoigooVmlMaseh5o9qeQQ
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 21:19:01 -0000

In message <20150103143226.GC13599@besserwisser.org>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 (lear@cisco.com):
> > 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: marka@isc.org