In message <20150103143226.GC13599@xxxxxxxxxxxxxxxx>, =?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@xxxxxxxxx): > > 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@xxxxxxx