Re: [quicwg/base-drafts] HTTP/QUIC without Alt-Svc? (#253)

[ThomasSwindells <[e-mail]>]

There are a number of different scenarios and interactions that I think need to be considered in this discussion, I’ll try to capture the two main ones below.
For precision and clarity I come from a CDN background and so will define some terms and concepts I’m using below – they may or may not perfectly match how other parts of the community use the same term hence why I’m going to give a brief description of how I’m using them here.

Client: The user agent which is presenting a URI in order to receive the content from the site that that URI is identifying.
Site: A hostname grouping together a set of paths which identify some resources sourced from one or more origin servers, we can assume the resources identified are the same regardless of delivery protocol (http, https, quic).
Origin Server: An authorative source for the resources within a site. If being fronted by delivery nodes then the origin may not be directly accessible by clients and may not deliver content over the same protocols as the delivery nodes are delivering to the client.
Delivery Node: Client accessible servers capable of serving resources from one or more sites. In a world wide distributed CDN there could be hundreds or even thousands of delivery nodes with request routing being used to direct client to particular nodes. Different delivery nodes may be on different software versions or have different specializations.
Request routing: the process by which a client requesting the URI gets connected to an appropriate delivery node capable of delivering the requested resource. There are a number of different ways that request routing can be implemented:
DNS based Request Routing: the site hostname gets resolved into one or more IP addresses of the delivery nodes, dependant on where you are (and the state of the delivery nodes etc) the list of IP addresses may differ.
HTTP 30x based request routing: The client initially connects to a request routing application, this returns a 302 redirect containing a URL pointing at a specific delivery node (by ip or hostname) and updated path.
Resource based request routing: The results of an API call or contents of a resource provide a URL directing subsequent requests to a specific delivery node. For instance the ‘base-url’ element of a DASH manifest may contain one or more URLS to delivery nodes.
Anycast based request routing: All delivery nodes share the same address and the network routes the connection to the closest node.

One particularly implication of this definition is whilst we could assume that all sites will be dual stack, this doesn’t imply that every delivery node for that site would be capable of being dual stack. This could be some nodes haven’t been upgraded to be dual stack, or some nodes may be specialised just to do HTTPs or just to do quic.

The key scenarios that we need to ensure we have a solution covering:
1. Resource has no knowledge of client capabilities, or delivery node capabilities
This is the case most discussion has been around. A static webpage linking to another host doesn’t know whether that site supports both https and quic, nor does it know if the client supports quic or not. The obvious solution is therefore to use an https uri for the link and expect the client to upgrade the connection to quic if it detects (or has remembered) that the server support it. This approach is simple and effective (particularly for single server sites).
There are some implications that this approach causes however (particularly when there are a large number of delivery nodes that can serve the site):

-          Every delivery node must support both https and quic

-          Much on the work on minimizing round trips at connection start are irrelevant if the client first has to make a TCP connection

-          The delivery node is placed under higher load, having to perform additional TCP session establishment and TLS negotiations on that temporary TCP connection. For repeat visits to a single server site the client can remember the QUIC support and potentially optimize the TCP connection away, for a multi-server site the client may get a different delivery node every time and so have to do the capability

2. Server has knowledge of client capabilities and wishes to direct the client to another delivery node for which it knows the capabilities
When either 30x or Resource based request routing is being performed the server can know if the client is quic capable (e.g. it is communicating over quic already) and also know if the target delivery node is quic capable. In fact for high throughput I would expect that it is desirable to have delivery nodes which are specialized to only do quic and not be dual stack - the two protocols require different code to access the different networking apis or may be able to take advantage of specific hardware acceleration etc.
With a 30x response there may be the option of returning an alt-svc header and hoping the client immediately switches to quic, however with resource based direction then the mechanism would need to work just through what can be learnt via the URL.

You’ve outlined four potential ways that given just a URL the ability for quic to be used directly could be achieved:

1.       Rely on alt-svc and the assumption all delivery nodes are dual stack. This limits flexibility and optimizations that could be done with a node only delivering quic packets.

2.       Alt-svc in DNS. This seems a technically viable approach although I can’t judge what complexities there are in introducing this and allowing applications to be able to access the information. A human reading the URL also can’t tell what protocol it is for.  For a browser same-origin policies may not be tripped when the client switches between protocols (which is probably a good thing)

3.       Adding an indicator into the port number (:q443). As others have mentioned this is almost certain to break existing URL parsers and APIs which typically use an integer datatype.

4.       Define httpq as an explicit protocol. This is clear what protocol the urls are for, although may have issues around same-origin semantics and may sometimes cause issues if the scheme isn’t defined on the os/programming language.

It may be one solution doesn’t fit all the usecases and the flexibility of multiple of them is what we end up needing:
1. may be suitable (and possibly even best) when used with web browsers/human shared links and where the browser is expected to use https initially and rely on alt-svc
2. could be used to inform clients that quic is supported and to immediately use quic.
4. could be used for m2m interactions (manifest files, request routing, api responses etc) when the capabilities of the client can be assumed/mandated and explicit control over the protocol is desired.

Thomas

From: Mike Bishop [mailto:[e-mail]]
Sent: 28 March 2017 06:54
To: quicwg/base-drafts <[e-mail]>
Cc: Subscribed <[e-mail]>
Subject: Re: [quicwg/base-drafts] HTTP/QUIC without Alt-Svc? (#253)


We've talked about four routes here:

1.   Long live TCP. All HTTP sites will be dual-stack, and the authoritative endpoint will be TCP. Clients MUST have a way to find the secure delegation from that TCP endpoint to QUIC, though we might define alternatives to Alt-Svc headers which could be done without TCP. (Alt-Svc in DNS?)

2.   Update RFC3986. RFC 3986 explicitly states that "The type of port designated by the port number (e.g., TCP, UDP, SCTP) is defined by the URI scheme." We could update the URI to contain a protocol designator, whose default is defined by the URI scheme. As it would be omitted in all existing URIs, their interpretation remains unchanged. Then https://www.example.com:q443/ refers to QUIC on UDP 443.

3.   Define a new scheme. See pull request.

4.   What's it matter? Assume that HTTP/QUIC on port 443 is likely equivalent to HTTP/TCP on port 443 if the cert is valid and call it good.

We explicitly do not consider the same host on different ports equivalent authorities, even if they happen to be listening on both ports with the same cert. Why is TCP 443 vs. UDP 443 any different from TCP 443 vs. TCP 444? (4) seems like a security issue waiting to happen.

I'm going to reverse myself and disagree that (3) is undeployable on the web in the near-term. App-to-app handoff on many (most?) platforms now uses custom URI schemes. Apps that encounter unknown URI schemes ask the OS; the OS is able to invoke appropriately-registered apps or tell the user they need to get a capable app. E.g. launching "nonsense://" produces this on Win10:

[image]<https://cloud.githubusercontent.com/assets/4273797/24390519/18b217aa-134f-11e7-8c13-22a24805081b.png>

Some cursory testing shows that browsers block navigations to URI schemes that don't have an OS-registered handler. But if you have two browsers, one QUIC-capable and one not, when you click an httpq:// link in the non-QUIC browser the OS will launch the QUIC-capable browser for you and you proceed on your merry way. This seems almost exactly what we'd want to have happen.

(2) probably is undeployable, because legacy apps will attempt to parse the URI and declare it invalid. They're semi-used to seeing unknown schemes (xboxliveapp-1297287741://, anyone?), but changes that break the parsers would be seriously painful.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/253#issuecomment-289670798>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AYUiYv1WvV7FWHoVg1SHdKHOUYV5Ekbfks5rqKCCgaJpZM4LzLA5>.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/253#issuecomment-292560741