Re: Indicating Chosen Service #443

On Mon, Mar 31, 2014 at 12:37 PM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> >From @mnot in #443:
>
> It's likely necessary for the server to know which protocol the user
> agent has chosen, and perhaps even the hostname (for load balancing).
> At the very least, there should be a flag in SETTINGS that indicates
> that an alternate service has been used.
>
> >From me:
>
> How is it that the combination of the protocol that is actually in
> use, and maybe Via, is not sufficient?
>
> As in, you get a connection from a client, using HTTP/2.  That's
> usually a good sign that they are connecting via HTTP/2.
>
> Presumably you know the names you can be reached by (it isn't always
> true that you know what DNS records point to you, conceded, but let's
> pretend that you aren't operating completely blind).  But that doesn't
> matter, because what's actually important is what domains you are
> claiming to be authoritative for, which you have to know.
>
>
So, why?
>
>
This is particularly important when using the ALTSVC frame to send traffic
to a different hostname but the same protocol, especially if any individual
server might have many hostnames by which it could be reached, and if the
hostname sets are overlapping.  The ALTSVC hostname is routing information,
and if the recipient of the connection doesn't have this information it can
be problematic to avoid loops, provide stickiness, troubleshoot, and know
where load is coming from for load-balancing purposes.

For example, if you return "ALTSVC: port=443, proto=h2t, host=
us-east-1.example.com, max-age=360" for www.example.com then it's highly
valuable for the server at us-east-1.example.com to know that it was
reached that way (as it might also have us-east-2.example.com and
us-east-1.example.org pointing to it).  This would allow it to: 1) know
that it shouldn't return another ALTSVC frame immediately (loop
prevention); 2) give some sense for other preferable ALTSVC host values
should be for nearby session affinity if returning another ALTSVC before a
GOAWAY/DRAIN; 3) allow it to log how clients got there for diagnostics
purposes; and 4) allow it to report load properly associated with
us-east-1.example.com, especially if other DNS names could have been used
to reach it.

Not all scenarios will require all of these.  However, not passing through
routing information to servers that can be reached multiple ways has turned
out to be unfortunate down the road for multi-tenant situations (lack of
manditory Host header in the first HTTP versions, lack of SNI in TLS, etc).

           Erik