Subject: preconnect link relation and ALTSVC frame

From: Lucas Pardue <[email-masked]>
Date: Wed, 8 Nov 2017 15:32:04 +0000

Hello,

Reading around the Web Linking [1] topic a bit, I came up with the following scenario involving preconnect [2]. My general question is, could a client act on Alt-Svc information during its preconnect action (and if so, do any implementations do this). I wondered if anyone had been on this thought journey and had an opinion.

  1.  Client makes a request for https://example.org/foo
  2.  Server responds with foo resource and Link header:
     *   Link: <https://bar.example.org>; rel=preconnect
  3.  Client attempts to initiate a preconnect and performs full connection handshake.
     *   During TLS handshake, ALPN selects H2
  4.  Connection is established and server sends an ALTSVC frame containing an Alt-Svc-Field-Value of:
     *   hq=":50781”, h2=”baz.example.org”
  5.  Client attempts to establish connection to one of the alternatives?

Regards
Lucas

[1] https://tools.ietf.org/html/rfc8288
[2] https://www.w3.org/TR/resource-hints/#preconnect

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

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

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

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 9 Nov 2017 05:54:54 +1300

On 09/11/17 04:32, Lucas Pardue wrote:
> Hello,
> 
> Reading around the Web Linking [1] topic a bit, I came up with the 
> following scenario involving preconnect [2]. My general question is, 
> could a client act on Alt-Svc information during its preconnect action 
> (and if so, do any implementations do this). I wondered if anyone had 
> been on this thought journey and had an opinion.
> 
>      1. Link: <https://bar.example.org>; rel=preconnect
>      1. During TLS handshake, ALPN selects H2
>      1. hq=":50781”, h2=”baz.example.org”

Firstly, why would a client do (5) immediately after (3) ? The whole 
point of preconnect is to avoid the latency / RTTs doing (5) would 
incur. Normally I would expect a client needing multiple connections to 
preconnect all of them ASAP - ie at (3) to avoid the latency, not 
waiting until after (4).

Secondly, if another connection were necessary sometime after (4) there 
is effectively no difference for the client between connecting to 
bar.example.com:443, bar.example.com:50781 and baz.example.org when 
fetching URLs for "http://bar.example.org". That is required or they 
would not be valid as alternatives for each other.

AYJ

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 8 Nov 2017 17:31:57 +0000

Hi Amos,

I'm not sure I follow your response.

>
> Firstly, why would a client do (5) immediately after (3) ? The whole point of
> preconnect is to avoid the latency / RTTs doing (5) would incur. Normally I
> would expect a client needing multiple connections to preconnect all of them
> ASAP - ie at (3) to avoid the latency, not waiting until after (4).

The sequence is serial. This isn't another Link header, this is the target of a preconnect telling the connection initiator to move on via an ALTSVC frame. An example use case for this would be to warm up a QUIC connection. There is no QUIC URL that can be used with preconnect to tell a client to go directly there.

In step 4, https://bar.example.org  presents new information to the client, that alternatives to are available. Step 5 was intended to ask whether the connection to alternative is chained to the preconnection activity (in other words, only complete once alternatives are tested and chosen, or ignored).

> Secondly, if another connection were necessary sometime after (4) there is
> effectively no difference for the client between connecting to
> fetching URLs for "http://bar.example.org". That is required or they would
> not be valid as alternatives for each other.

Right, so in a subsequent request, a client effective request URI for https://bar.example.org/bar would be issued to one of the pre-warmed alternatives. For example, to the HTTP/QUIC endpoint running on bar.example.org:50781.

Kind regards
Lucas

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Mike Bishop <[email-masked]>
Date: Wed, 8 Nov 2017 18:47:59 +0000

ALTSVC dosen’t say “move on,” it provides information about better options.  The client can legitimately continue to make requests on that connection and keep the Alt-Svc info for next time, or it can try to act on it now.  I don't know whether any browsers do this, but one logical implementation would be:

  *   Client begins opening the connection to the Alternative
  *   When a request needs to be made, it uses whichever already-established connection is most preferred

Amos is right that the point of Preconnect is to save the connection establishment time from blocking the download of resources; that would suggest that the client wouldn’t ever block waiting for an alternative to become available, but might reasonably race the connection establishment with the generation of the request.

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, November 8, 2017 9:32 AM
To: Amos Jeffries <[email-masked]>; [email-masked]
Subject: RE: preconnect link relation and ALTSVC frame

Hi Amos,

> incur. Normally I would expect a client needing multiple connections

> to preconnect all of them ASAP - ie at (3) to avoid the latency, not waiting until after (4).

> Secondly, if another connection were necessary sometime after (4)

> there is effectively no difference for the client between connecting

> to bar.example.com:443, bar.example.com:50781 and baz.example.org when

Kind regards

Lucas

http://www.bbc.co.uk

information in any way nor act in reliance on it and notify the sender immediately.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 8 Nov 2017 19:58:52 +0000

Hi Mike,

I think we're all in agreement, the example sequence I gave is a simplification where in reality there will be things happening in parallel. Id presume the racing kind of behaviour you describe could be applied equally here. 

"Move on" was a figure of speech and a bad choice :) Its important to remember that preconnect and alt-svc are hints and it's up to clients to determine how/when they are used. There are many factors here, coalescing to name but one.

I can imagine a future where H2 servers "default" to sending ALTSVC frames immediately on connection establishment, due to QUIC being preferred. My imagination may not be grounded.

Turning this around. A preconnect for a URL that corresponds to an entry that exists in a client's Alt-Svc cache, I would think that a new connection to the alternative would be opened.

Lucas
________________________________________
From: Mike Bishop [[email-masked]]
Sent: 08 November 2017 18:47
To: Lucas Pardue; Amos Jeffries; [email-masked]
Subject: RE: preconnect link relation and ALTSVC frame

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, November 8, 2017 9:32 AM
To: Amos Jeffries <[email-masked]>; [email-masked]
Subject: RE: preconnect link relation and ALTSVC frame

Hi Amos,

Kind regards

Lucas

http://www.bbc.co.uk