Re: #385: HTTP2 Upgrade / Negotiation

Some thoughts after having read through this thread on the flight over...
(Note that some of these are skewed from the perspective of having
spent too much time staring at one particular CDN / Acceleration Gateway
over the years, but I think some are generally applicable.)


* Any multi-port negotiation and caching (ie, for an
  Alternate-Protocol) may make sense to consider in conjunction with
  "Alt-Server" (see draft-nygren-httpbis-connection-redirect which I need
to post
  an updated version of soon) as they have quite a bit of similarity.
  One consideration in this area is that the Alternate-Protocol hint could
additionally convey the
  urgency of making the switch (e.g., as an option along with the hint
  indicating whether the switch should be synchronous or
  asynchronous).  In many cases it might be reasonable for the client
  to continue using the HTTP/1.1 connection in-parallel with
  establishing and migrating to the HTTP/2.0 connection.


* One reason Alternate-Protocol is potentially attractive as an
  option: when using it to switch to http2-over-tls (with cert
  validation), we could require that it only be used by clients which
  MUST support TLS-SNI.  This addresses at least one issue with TLS.
  (One BIG problem with manditory TLS-with-cert-validation in my view
  is that there isn't enough IPv4 space left to sanely manage the
  limitation of a Host-per-IP-address resulting from the slow rate of
  TLS-SNI adoption.  Providing a way to upgrade to TLS for individual
  connections and only for clients that support TLS-SNI can help
  here.)


* SRV records aren't too bad from a RTT perspective for sites already
  using CNAMEs as part of their setup (such as is common with some
  CDNs).  This is only one use-case as a counter-point to some of the
  other use-cases discussed here.  For example, if lookups for A and
  SRV records are made in parallel for this set of hostnames, the same
  number of round trips is involved:

     www.example.com CNAME www.example.com.example-cdn.net
     www.example.com.example-cdn.net A 10.2.3.4
     www.example.com.example-cdn.net A 10.2.3.5
     www.example.com.example-cdn.net AAAA  2001::abcd

     _http2._tcp.www.example.com SRV 0 10 80 _
http2.www.example.com.example-cdn.net
     _http2.www.example.com.example-cdn.net A 10.2.3.4
     _http2.www.example.com.example-cdn.net A 10.2.3.5
     _http2.www.example.com.example-cdn.net AAAA  2001::abcd

  Note that it would not be surprising if some
  integrations sometimes resulted in names further down the chain like
  _http2.www.example.com.example-cdn.net sometimes returning NXDOMAINs.

  It is annoying that the SRV record ends up needing to be under the
  domain of control of initial authority rather than of the actual
  server operators.  One approach here might be for the domain
  authority to CNAME the SRV record name over to a server operator
  (eg, CDN) which could address this concern (but won't help for names
  that can't be CNAMEs):

     _http2._tcp.www.example.com CNAME _http2._
tcp.www.example.com.example-cdn.net
     _http2._tcp.www.example.com.example-cdn.net SRV 0 10 80 _http2._
tcp.www.example.com.example-cdn.net
     _http2._tcp.www.example.com.example-cdn.net A 10.2.3.4
     _http2._tcp.www.example.com.example-cdn.net A 10.2.3.5
     _http2._tcp.www.example.com.example-cdn.net AAAA  2001::abcd

  As a side-note, having SRV records work sanely for HTTP would
  help in the unfortunate cases of names like "example.com"
  where a CNAME isn't allowed or supported by DNS.


* A downside of using a finer-grained prototocol version in SRV
  records (eg, "_http2_draft1") is that they are hard to get
  third-parties to deploy frequently (eg, for customer sites of a
  CDN).  As such, it may make sense to leave this as just "_http2" and
  make sure that the initial HTTP/2 draft wire versions can signal
  protocol versions and trigger a downgrade if needed.


* One complication for client authors to consider here is the matrix
  of HTTP/2 -> HTTP/1.1 fall-back behavior mixed with IPv6 -> IPv4 fall-back
  behavior.  There are perhaps some lessons to be learned from the
  IPv6 "happy eyeballs" work here as well (although the behaviors
  implemented there tend to involve much earlier fall-back from a failure
  to establish the TCP connection fast enough, while the protocol-level
  fallback is presumably higher in the stack).


* +1 to: Having a new scheme (ie, http2://) as an option seems
  potentially useful, but it shouldn't be manditory, and shouldn't be
  a primary way to operate.


One proposal might be:

1) Use HTTP/2 if the http2 scheme is specified.

2) Perform SRV record lookups in-parallel with A/AAAA lookups.

3) For HTTPS, use TPS+NPN even if the SRV record lookup failed.

4) For non-TLS, accept Alternate-Protocol hint which triggers a new
connection
    establishment  (perhaps asynchronously, as that also helps if an
alternate
    port is unavailable?)

5) An open question is whether we also want a synchronous "Upgrade"
     option as well on the same port.  (The transparent/interception proxy
issue
     seems to be the biggest risk here...)