Re: on DNS records

On 14/11/2012, at 2:07 AM, Eliot Lear <lear@cisco.com> wrote:

> As I promised last week, I've substantially developed a draft (and some code) to look more closely at whether a DNS record can be helpful.  Before I get it out there, I wanted to check goals.  The situation is this: there is a 2.0-enabled client and it must determine whether or not the other end can speak 2.0.  Gabriel and Willy have already shown us that it can be done INSIDE the protocol at the expense of one roundtrip, but at the risk of a proxy doing the wrong thing (a classic case being that it allows an Upgrade: header but then barfs all over the upgrade).  So let's state our goals:
> 
> 1.  Keep latency down.
> 	• First, is this a reasonable goal?

Safe assumption that it is.


> 	• Can it reasonably be done better than what Willy & Gabriel have laid out?

That's what we're here to find out -- keeping in mind that we're looking for an *optimisation* over the upgrade mechanism at this point, not a replacement for it.


> 2.  Transport Protocol Discovery
> 	• Some have suggested that it would be useful to do HTTP over UDP or SCTP.  Is that something that is a reasonable goal?

Based on the conversations I've heard, yes.


> 3.  Handle the case where multiple instances of the same application protocol reside on the same host, but on different ports.
> 	• Is this a reasonable goal?

Nice-to-have at most, I'd say. I.e., I personally would be OK saying that the DNS-based optimisation doesn't work for HTTP URIs that specify a non-default port. Yes, we may not be able to get the first round-trip to our router configuration page perfectly optimised, but that's a reasonable price to pay for simplicity. What do others think?


> 4.  No new URI schema
> 	• Address the 'side of the bus' problem.
> 	• Is this a reasonable goal?

Treat it as a fundamental constraint, at least for now.


> Does this about cover it?  I claim we can solve all four, but not easily with SRV.

One other requirement is that it's capable of advertising a range of options, not just binary "use HTTP2?". Doesn't have to be an infinite range, small set will do, I think.

A few more things to tease out:

- Are we advertising that port 80 is capable of HTTP/2, or an alternate port for HTTP/2, or (capable of) both?
- Are we allowing the advertisement to resolve to a different host, or restricting to the named host (a la Alternate-Protocol)?

Regards,

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 14 November 2012 23:43:51 UTC