Subject: Alt-Svc-Used indicator granularity (ext#34)

From: Erik Nygren <[email-masked]>
Date: Fri, 22 Aug 2014 18:38:08 -0400

For discussion of https://github.com/httpwg/http-extensions/issues/34

-----------------

 The current Alt-Svc-Used indicator is a boolean ("0"/"1"), due to the
desire to preserve privacy.
Based on some explorations of how this would be implemented on the server
side, we realized that this doesn't provide enough information to
distinguish between the different use-cases for Alt-Svc. In particular, a
server would have no way to know if just the protocol was changed, or if
both the protocol and host were changed. If we start using multiple Alt-Svc
sources (such as DNS) this also becomes relevant.

An option short of including (proto,host,port) in Alt-Svc-Used would be to
include a better indicator of how the Alt-Svc was used. This could be
either a bitmask or a string of tokens. For example, with a bitmask:

   - 1 = Alt-Svc was used to change protocol (ie, service proto != default
   origin scheme's proto)
   - 2 = Alt-Svc was used to change port (ie, service port != origin port)
   - 4 = Alt-Svc was used to change host (ie, service host != origin host)
   - 8 = Alt-Svc was obtained via Alt-Svc header
   - 16 = Alt-Svc was obtained via ALTSVC frame
   - 32 = Alt-Svc was obtained via DNS record (reserved, not yet defined)

With a token approach, short character strings could replace the bitmask.
In either case this would result in a value like:

Alt-Svc-Used: 20
Alt-Svc-Used: h,f

For load-balancing, this would make it possible to infer the
(proto,host,port) that may have been used in cases where it differs by
use-case but is consistent within a use-case.

This would also significantly help with debuggability on the server side.

(that Issue also mentions some editorial issues that we should resolve
after answering this.)

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Aug 2014 17:06:09 -0700

I can potentially see why it might be interesting to learn about the
difference between shifting load and upgrades of various sorts.  But
if that is all that you need, then we probably want to limit the
information to just that.

Knowing where the information came from is a common marketing
requirement, but separable.  Do you really believe that you will have
so many sources of leads that you will have to have some sort of
...Referer... that allows you to identify bad leads?

Incidentally, based on some other discussions that I've had, I've
basically concluded that the privacy leak isn't much alleviated by the
reduction in entropy on this field, so I'm open to re-opening that
discussion if you feel that would make this more straightforward.  But
I think that I'd still be pushing for a reduction to zero, which would
remove what is a non-trivial disincentive to use Alt-Svc in some use
cases.

On 22 August 2014 15:38, Erik Nygren <[email-masked]> wrote:
> The current Alt-Svc-Used indicator is a boolean ("0"/"1"), due to the desire
> to preserve privacy.
> include a better indicator of how the Alt-Svc was used. This could be either
> a bitmask or a string of tokens. For example, with a bitmask:
>
> 1 = Alt-Svc was used to change protocol (ie, service proto != default origin
> scheme's proto)
> 2 = Alt-Svc was used to change port (ie, service port != origin port)
> 4 = Alt-Svc was used to change host (ie, service host != origin host)
> 8 = Alt-Svc was obtained via Alt-Svc header
> 16 = Alt-Svc was obtained via ALTSVC frame
> 32 = Alt-Svc was obtained via DNS record (reserved, not yet defined)
>
> (that Issue also mentions some editorial issues that we should resolve after
> answering this.)
>
>

---

From: Erik Nygren <[email-masked]>
Date: Sat, 23 Aug 2014 21:23:23 -0400

> information to just that.

At least one primary use-case that I know about is for load feedback as
part of a load balancing control system.  Some types of control systems
need to split up load by how it got to the destination, especially if there
are many potential ways this could have happened.  Since load balancing is
one of the primary use-cases described in the document, this is where it
matters.  (This isn't a marketing use-case at all.)

Another use-case is an input into whether to return an Alt-Svc header or
frame.  Whether the client
is already using one and which one was used by the client seems to play
into most of the more obvious
algorithms here.

The initial proposal was just to include what was used to make the
connection.  For example:

     Host: www.example.com
     Alt-Svc-Used: h2="server-west.example.com:443"

Using a few bits for Alt-Svc-Used enables some degree of inference.
It won't tell you if the client used server-east or server-west, but if
there are
separate bits for changed-proto from changes-host, you can at least figure
out if it was server-*.example.com or www.example.com.
But just a single bit for Alt-Svc-Used doesn't even allow a server
to distinguish that if both modes might be in-use.

> remove what is a non-trivial disincentive to use Alt-Svc in some use

I do think that using something like the above with the alternate service
that was ysed
would be the most straight-forward.

     Erik