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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, =?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 ([e-mail]):
> > 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                             [phone]
> You mean you don't want to watch WRESTLING from ATLANTA?
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]