RE: preconnect link relation and ALTSVC frame

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 [mbishop@evequefou.be]
Sent: 08 November 2017 18:47
To: Lucas Pardue; Amos Jeffries; ietf-http-wg@w3.org
Subject: RE: preconnect link relation and ALTSVC frame

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:Lucas.Pardue@bbc.co.uk]
Sent: Wednesday, November 8, 2017 9:32 AM
To: Amos Jeffries <squid3@treenet.co.nz>; ietf-http-wg@w3.org
Subject: RE: preconnect link relation and ALTSVC frame



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 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.



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.

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

Received on Wednesday, 8 November 2017 19:59:29 UTC