Re: Upgrade status for impl draft 1

On Thu, Feb 21, 2013 at 08:11:08PM +1100, Mark Nottingham wrote:
> Based upon discussion both at the Interim and subsequently, this is where I
> think we are for the upgrade/negotiation process, at least in terms of the
> 1st implementation draft:
> 
> 1. HTTPS URLs
>    - use NPN (or its replacement); uses OPAQUE TOKEN to negotiate
>    - NO magic
>    - SETTINGS first
> 
> 2. HTTP URLs
> 
>   a. existing connection / new connection without context
>       - Upgrade Dance; uses OPAQUE TOKEN to negotiate
>       - NO magic
>       - SETTINGS first
> 
>   b. new connection with context (e.g., because you used DNS hint, header
>   hint, prior knowledge)
>      - NO upgrade dance
>      - Magic
>      - SETTINGS first
> 
> The decision as to whether to use 2(a) or 2(b) in a particular situation is
> up to implementations, but of course we'll give (non-normative) guidance.
> 
> Does this make sense to everyone?

I'm still having a problem with the principle behind 2b : when you
pass through transparent intercepting proxies, by definition you're
not aware of it. So even if 2a worked for the first connection, it
does not preclude that 2b will work for the second one. Nor the DNS
will BTW.

And the issue I'm seeing is that 2b will require HTTP/2->2 proxies to
be deployed along all the path for this to succeed. If 2->1 proxies
are deployed, then we lose all benefits for 2.0 by terminating the
optimizations close to the client. Let's consider the following
common path :

  [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]

ISP proxy is the transparent proxy/cache at the client's ISP's, and SRV
proxy is the ADC on the server side. Eventhough the server side is fully
2.0 compatible and advertises it via the DNS, until the ISP proxy is not
a true 2.0->2.0 proxy, we'll have the following possibilities :

Upgrade connection : creates a tunnel between CLI and server, end-to-end
2.0 (just like with TLS) :
          2.0                      2.0                      2.0
  [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]

Magic, ISP proxy not aware at all : second connection fails, client has
to fall back to 1.1 (or switch back to Upgrade ?) :
          1.1                      1.1                      1.1
  [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]

Magic, with ISP proxy being a 2.0-to-1.1 gateway :
          2.0                      1.1                      1.1
  [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]

Magic, with ISP proxy being a 2.0-to-2.0 gateway :
          2.0                      2.0                      2.0
  [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]

The last case (2.0-to-2.0 gateway) will not happen soon, and I really
believe that because of this, we'll be much more often in second then
third case above where 1.1 only is used on the long path.

Likewise, it is not said how such 2.0 should pass through explicit proxies,
while the Upgrade provides such a solution.

Why not consider the Upgrade request the "magic" itself ? In fact it's
exactly that. I understand the complexity that the Upgrade can cause if
we require the server to process the early requests in 1.1. But if we
consider that it's just a prefix, there is no "dance" at all. It's just
the same as what was proposed in 2817 for TLS upgrade, we connect to the
other endpoint and establish a tunnel. No need to support multiple setup
methods.

Regards,
Willy

Received on Friday, 22 February 2013 07:02:44 UTC