ietf
[Top] [All Lists]

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

2015-01-03 15:19:22

In message <20150103143226(_dot_)GC13599(_at_)besserwisser(_dot_)org>, 
=?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(_at_)cisco(_dot_)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(_at_)isc(_dot_)org

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