RE: Interest in a UDP equivalent to the CONNECT method

So to summarise the discussion on a few of the different threads that this launched:


  *   There seems to be some interest in this idea.
  *   HTTP/QUIC is one use case that does not suffer from peer-to-peer UDP issues.
  *   WebRTC is one use case that does suffer from peer-to-peer UDP issues
     *   There is overlap with TURN, which may be good or bad.
  *   Question: Are there enough compelling use cases to justify a new method?
     *   Corollary: would one high-impact use case be sufficient to justify a new method?

Apologies if I missed anything out.

Based on this feedback I’m inclined to write up a more rounded technical proposal to help frame further discussion. This might separate out the WebRTC theme to disentangle the different aspects.

Regards
Lucas

From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]
Sent: 03 February 2018 14:28
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: bemasc@google.com
Subject: Interest in a UDP equivalent to the CONNECT method

Hi,

I'm wondering if there is interest from the WG in the following space before investing any more technical effort.

It recently struck me that there might be a use in iterating upon the CONNECT method, in order to support a world of UDP servers that support HTTP/QUIC. That spec neatly summarises the current state of play:

   In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a

   tunnel to a remote host.  In HTTP/2, the CONNECT method is used to

   establish a tunnel over a single HTTP/2 stream to a remote host for

   similar purposes.



   A CONNECT request in HTTP/QUIC functions in the same manner as in

   HTTP/2.  The request MUST be formatted as described in [RFC7540],<https://tools.ietf.org/html/rfc7540#section-8.3>

   Section 8.3<https://tools.ietf.org/html/rfc7540#section-8.3>.  A CONNECT request that does not conform to these

   restrictions is malformed.  The request stream MUST NOT be half-

   closed at the end of the request.



   A proxy that supports CONNECT establishes a TCP connection

   ([RFC0793<https://tools.ietf.org/html/rfc0793>]) to the server identified in the ":authority" pseudo-

   header field.  Once this connection is successfully established, the

   proxy sends a HEADERS frame containing a 2xx series status code to

   the client, as defined in [RFC7231], Section 4.3.6<https://tools.ietf.org/html/rfc7231#section-4.3.6>.

The sad part here is that an HTTP/QUIC client that uses an HTTP/QUIC proxy in this mode needs to support TCP for secure connection to the remote host. This presents some resistance to moving away from TCP in the future.

I wondered if something better could exist, and Ben Schwartz and I batted some ideas around. The strongest one was the idea of a new method (e.g. UDPBIND) that would allow a client to indicate to the proxy that it wished to communicate with the remote host using UDP. Depending on the protocol being used for client-to-proxy communication some options present themselves (NB: the data exchanged is the serialization of TLS handshake and protected packet format):

  *   HTTP/QUIC

     *   DATA frames sent by client (UDP) are transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is packaged into DATA frames, which are then transmitted to the client (UDP).

  *   HTTP/2

     *   DATA frames sent by client (TCP) are transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is packaged into DATA frames, which are then transmitted to the client (TCP).

  *   HTTP/1.1 ?

     *   data sent by the client (TCP) is transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is transmitted to the client (TCP).

The conversion between TCP and UDP should be treated carefully, payloads may be segmented unexpectedly.

The handling of UDP "closure" is a problem area that needs more thought.

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.

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