Subject: SETTINGS frame - not documented as peer-to-peer only

From: Robert Collins <[email-masked]>
Date: Tue, 30 Sep 2014 10:17:14 +1300

When reading the websockets draft, it occured to me that perhaps I
misunderstand SETTINGS. AIUI it is peer to peer, not end to end.

That is:

Client<->intermediary<->server.
A               B                        C

settings are exchanged between A and B, and B and C, but never A and
C, and settings from C are not propogated to A.

Further, because A doesn't know for any particular stream whether it
will traverse BC or perhaps BD (were D might be a load balanced
secondary IP for the same origin as C, or be a new ALT-SVC being
warmed up), there is no way in the HTTP/2 model to talk about the
BC/BD capabilities to A.

Case in point, if C is capable of e.g. websockets, and so is B, we
don't know if D is. So B can't hide its websocket readiness until it
sees C is ready too - thats conflating stream capabilities with peer
capabilities?

Perhaps in section 6.5, after
"SETTINGS parameters are not negotiated; they describe characteristics
of the sending peer, which are used by the receiving peer. Different
values for the same parameter can be advertised by each peer. For
example, a client might set a high initial flow control window,
whereas a server might set a lower value to conserve resources."

"SETTINGS frames MUST NOT be forwarded - they are solely used to
negotiate the characteristics of a single connection between two
endpoints.

It also raises questions in my mind about SETTINGS_ENABLE_PUSH

Given

Client1
Client2
Proxy
Server

If client1 has SETTINGS_ENABLE_PUSH=1, and client2 has
SETTINGS_ENABLE_PUSH=0, the Proxy has SETTINGS_ENABLE_PUSH=1, then the
server may push resources for both clients, and the proxy will have to
cancel streams when they are for client2 ?

That is surely doable but seems a little wasteful. I wonder if we can do better?

-Rob

-- 
Robert Collins <[email-masked]>
Distinguished Technologist
HP Converged Cloud

---

From: Stuart Douglas <[email-masked]>
Date: Tue, 30 Sep 2014 08:09:18 +1000

> cancel streams when they are for client2 ?

This is exactly this issue that I raised last week[1], although I was 
talking about the case when you are using a HTTP2 load balancer that 
also has HTTP 1 clients, although the same issue arrises when you have 
HTTP2 clients with push disabled. I raised an issue[2] but apparently it 
is too late to do anything about it.

Stuart

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2374.html
[2] https://github.com/http2/http2-spec/issues/621

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Sep 2014 19:45:39 -0700

> misunderstand SETTINGS. AIUI it is peer to peer, not end to end.

How else could this possibly work?

---

From: Stuart Douglas <[email-masked]>
Date: Tue, 30 Sep 2014 12:58:03 +1000

I think the real issue here is that SETTINGS_ENABLE_PUSH and the 
proposed SETTINGS_WEBSOCKET_CAPABLE are really end to end settings 
rather than just peer to peer. You need both endpoints and all 
intermediaries to support them for them for them to be used, and at the 
moment we have no way of discovering this. All you can really do is 
attempting a push / websocket connection and hope it works.

All other settings make sense as peer to peer settings, but I really 
don't think these two do.

Stuart

Martin Thomson wrote:
> On 29 September 2014 14:17, Robert Collins<[email-masked]>  wrote:

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 30 Sep 2014 13:15:19 +1000

On 30 September 2014 12:58, Stuart Douglas <[email-masked]>
wrote:

> I think the real issue here is that SETTINGS_ENABLE_PUSH and the proposed
> SETTINGS_WEBSOCKET_CAPABLE are really end to end settings rather than just
> peer to peer. You need both endpoints and all intermediaries to support
> them for them for them to be used, and at the moment we have no way of
> discovering this. All you can really do is attempting a push / websocket
> connection and hope it works.
>
> All other settings make sense as peer to peer settings, but I really don't
> think these two do.
>
>
​But you only push resources one hop (?). E.g. origin to caching proxy.

Also: enable_push goes from the push-receiver to the pusher. If all hops
along the way support it, you could theoretically get end-to-end pushes
(although I don't think such a thing is defined yet). If one hop along the
way doesn't support it, then what's the difference?

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

---

From: Robert Collins <[email-masked]>
Date: Tue, 30 Sep 2014 16:38:20 +1300

On 30 September 2014 16:15, Matthew Kerwin <[email-masked]> wrote:
>> peer to peer. You need both endpoints and all intermediaries to support them
>> for them for them to be used, and at the moment we have no way of
> But you only push resources one hop (?). E.g. origin to caching proxy.

No - its entirely legitimate to push private uncachable resources
"Caching responses that are pushed is possible based on the guidance
provided by the origin server in the Cache-Control header field.
However, this can cause issues if a single server hosts more than one
tenant. For example, a server might offer multiple users each a small
portion of its URI space."

> way doesn't support it, then what's the difference?

As I wrote, the client-most hope that supports push has to
receive-and-discard-or-cache-if-permitted all the pushed resources.
That, particularly for uncachable resources, will be a non-trivial
waste of CPU and network.

-Rob

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 30 Sep 2014 15:04:59 +1000

On 30 September 2014 13:38, Robert Collins <[email-masked]>
wrote:

> proposed
> them
> don't
> ​
That doesn't make it any less a single-hop push, or a single-hop setting.
You don't "need both endpoints and all intermediaries" for them to be used
(useful?) in *all* cases, just this one.

​
> ​
> ​
> ​

​
> waste of CPU and network.
Indeed. If it's that worrying, when your muxer gets a client that doesn't
support push, just send an upstream SETTINGS_ENABLE_PUSH(0). If that client
goes away, re-send the setting with (1).  If anything, this point furthers
the case that this isn't and cannot be an end-to-end setting, as Stuart
suggested, because end-to-end implies 1:1, and this is a 1:n situation.

If I were replying to your sub-thread (and we weren't past WGLC) I'd have
said: add a third value to SETTINGS_ENABLE_PUSH to say "only cacheable
resources", and/or introduce a per-stream setting (which I suppose
manifests as a HEADERS flag and/or extension frame) to toggle pushes in
response to a particular request. Note that you're well within your rights
to draft such an extension right now. If it's good, and gains support, it
could be pushed out pretty close to the core spec and maybe even get into
some implementations.

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 30 Sep 2014 09:18:36 +0000

These settings are just peer to peer, and it's possible to take advantage of them even if they are not supported end to end.

For example, in the configuration:
Client -> proxy -> server

The client can set SETTINGS_ENABLE_PUSH to false, the proxy can set it to true.
The server will push resources to the proxy, which can:
- Cancel the pushed resources
- Accept the pushed resources and cache them: it will be able to respond directly when the client will be asking them.

Hervé.

> -----Original Message-----
> From: Stuart Douglas [mailto:[email-masked]]
> Sent: mardi 30 septembre 2014 04:58
> To: Martin Thomson
> Cc: Robert Collins; HTTP Working Group
> Subject: Re: SETTINGS frame - not documented as peer-to-peer only
>