Subject: ext#7 / ext#8: multiple alt-svc

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Jul 2014 16:22:54 +1000

Martin opened two similar issues:
  <https://github.com/httpwg/http-extensions/issues/7>
  <https://github.com/httpwg/http-extensions/issues/8>

... regarding how to handle multiple advertised alternative services.

Personally, I'm not sure we need to specify this (see my comments in the issues).

What do others think? Martin, any further thoughts?

Cheers,

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

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 2 Jul 2014 16:54:53 +1000

> What do others think? Martin, any further thoughts?
Regarding ext#7, if I recall correctly whenever a list includes q-values we
don't tell anyone how to use them, beyond "bigger means better". (RFC
2295/2296 are experimental; does anyone else implement them?) I wouldn't be
against adding q-values to the alt-svc header to indicate a server-side
preference, if such a thing makes sense ("You can also get this here, but
I'd prefer you didn't"..?)

Currently any parameter is allowed, right? Even though only "ma" is defined.

Regarding ext#8, I'm actually interested to see the outcome of the decision
because my draft for compressed DATA frames has an equivalent "single
setting, multiple encodings" issue. If ALTSVC sets a precedent for updating
(rather than replacing), I'll feel less uncomfortable about my extension
setting -- even if that means moving the setting to Yet Another Frame Type.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Jul 2014 10:02:26 -0700

> What do others think? Martin, any further thoughts?

I think that we probably need to have text to clarify what each means,
but it should be relatively simple:

In both cases, I think that we can say that each advertisement of an
alternative service adds a new alternative to the set of alternatives
that is known to the client/recipient.

Then, when multiple alternatives are present, we let the client choose
the alternative it likes best.

Existing alternatives can have properties altered by selecting based
on the tuple [protocol, host, port] and providing new values for other
attributes.  Here I'm thinking that we enable forcibly expiring an
alternative by adjusting max-age.

I'm happy to provide a PR (or three) to this effect.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Jul 2014 10:00:03 +1000

> I'm happy to provide a PR (or three) to this effect.

WFM.

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Jul 2014 10:22:23 +1000

On 2 Jul 2014, at 4:54 pm, Matthew Kerwin <[email-masked]> wrote:

> Regarding ext#7, if I recall correctly whenever a list includes q-values we don't tell anyone how to use them, beyond "bigger means better". (RFC 2295/2296 are experimental; does anyone else implement them?) I wouldn't be against adding q-values to the alt-svc header to indicate a server-side preference, if such a thing makes sense ("You can also get this here, but I'd prefer you didn't"..?)
> 

Yes, any parameter is allowed, but ‘q’ is only a convention; it doesn’t have any meaning unless the header defines it.

So far, we see ‘q’ being paid only scant attention in existing headers; not sure it’ll really be better here. Again, the original scheme did have a prioritisation mechanism, but the feedback I got was that it’s too complex for no demonstrated gain.

> Regarding ext#8, I'm actually interested to see the outcome of the decision because my draft for compressed DATA frames has an equivalent "single setting, multiple encodings" issue. If ALTSVC sets a precedent for updating (rather than replacing), I'll feel less uncomfortable about my extension setting -- even if that means moving the setting to Yet Another Frame Type.

---

From: Kinkie <[email-masked]>
Date: Thu, 3 Jul 2014 07:02:52 +0200

> I'm happy to provide a PR (or three) to this effect.

To me this sounds like a step back compared to DNS SRV records, which offer
priority, weight and ttl.
https://github.com/httpwg/http-extensions/issues/7 suggests extending by
adding a "q=" parameter. IMHO that proposal is useful.
The selection algorithm can then be specified pretty simply: clients SHOULD
choose randomly one alternate server but it MUST be among the pool having
the highest-priority value.

It can be debated whether clients can retry to a different server requests
not having any side effects, but in that case the algorithm should be
pretty much the same as in the first round, after invalidating the failed
server(s).

I would not overload max-age however with this task however. If a "q="
parameter can be added, it should be possible to add a "max-age=" parameter
as well, isn't it? Unless the proposal is to define some mechanism to clear
the list of altsvc regardless of any other expiry information.

-- 
Francesco

---

From: Kinkie <[email-masked]>
Date: Thu, 3 Jul 2014 07:10:05 +0200

> So far, we see 'q' being paid only scant attention in existing headers;
not sure it'll really be better here. Again, the original scheme did have a
prioritisation mechanism, but the feedback I got was that it's too complex
for no demonstrated gain.

In an enterprise scenario, it could be used to implement reliable and
consistent multi-datacenter HA services: the priority can be used to hint
the client to choose the primary or the closest Datacenter,  and then
balance among a local servers pool.

   Francesco

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 3 Jul 2014 16:11:38 +1000

On 3 July 2014 15:02, Kinkie <[email-masked]> wrote:

> The selection algorithm can then be specified pretty simply: clients
> SHOULD choose randomly one alternate server but it MUST be among the pool
> having the highest-priority value.
>

If the client MUST choose from the highest priority pool, why would the
server ever bother sending those with lower values? Unless you're
suggesting the server-supplied q-values are combined with some client-side
preference metric to provide the final priority (a la RFC 2296)? Or are you
considering that, if the client attempts all the highest-priority
alternates and they fail, it can then move onto the lower priorities?

> the list of altsvc regardless of any other expiry information.

There's already a max-age ("ma") parameter "which indicates the number of
seconds [...] the alternative service is considered fresh for", the default
being 24 hours. Setting it to 0 automatically marks the alternate service
as stale, which I suppose means it's no longer available. That means being
able to send a second Alt-Svc header with the same [protocol,host,port]
tuple, but with "ma=0".

---

From: Kinkie <[email-masked]>
Date: Thu, 3 Jul 2014 08:19:24 +0200

Hi Matthew.,

I'm suggesting the latter. See the use case I gave in a different mail in
this thread.

>
>
>> It can be debated whether clients can retry to a different server
requests not having any side effects, but in that case the algorithm should
be pretty much the same as in the first round, after invalidating the
failed server(s).

Thanks for clarifying this for me. This would of course work.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Jul 2014 12:25:39 -0700

> priority, weight and ttl.

I'll note that if (and it's a pretty big if) we support DNS SRV, then
adding priorization and weight to the alternative service declaration
would be *in addition to* SRV.  I think that keeping this simple is
best, noting that the server can apply things like prioritization and
weighting *before* sending the alternative service indication out.
This is not an option in the DNS scenarios due to the DNS
architecture, i.e., caching, but it's totally feasible here.

There are some arguments for having the client be able to choose, but
isomorphism with SRV is not one of those.

---

From: Kinkie <[email-masked]>
Date: Fri, 4 Jul 2014 11:36:23 +0200

> architecture, i.e., caching, but it's totally feasible here.

DNS SRV has been out for a long time, and so far it hasn't gained
traction except in very specific cases for some reason.
Using ALT-SVC at the HTTP level has advantages over it however: it
allows to have easy, dynamic, server-driven load redirection and
redistribution policies.

> isomorphism with SRV is not one of those.

I agree. However feature-parity IMO is one such argument. Especially
if the needed change is - at least apparently - trivial.

-- 
    Francesco