Subject: [Masque] A proposal for CONNECT-UDP

From: David Schinazi <[email-masked]>
Date: Thu, 16 Apr 2020 20:01:02 -0700

Hi MASQUE enthusiasts,

The initial proposal for MASQUE was formulated as a
framework. draft-schinazi-masque-protocol-01
<https://tools.ietf.org/html/draft-schinazi-masque-protocol-01> goes into
the details, but the general idea was to have a unified
MASQUE negotiation step that would allow bootstrapping
other MASQUE applications (or services). Martin Thomson
pointed out that it may be simpler to build this if each
application/service handled its own negotiation, and there
seemed to be support for that idea. The current MASQUE
proposed charter (see other threads on this list) adopted
this methodology, discussing how to build these specific
applications individually, starting with UDP proxying.
To help folks reason about what that could look like, I
wrote up a short draft that defines the HTTP CONNECT-UDP
Method: draft-schinazi-masque-connect-udp
<https://tools.ietf.org/html/draft-schinazi-masque-connect-udp>
I hope this helps, please let me know what you think.

Thanks,
David Schinazi

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 17 Apr 2020 16:16:05 +1000

Hey David,

This seems like a reasonable general form for a solution.  I particularly like the idea of sending datagrams over the stream until you decide whether DATAGRAM frames are available.  The idea is quite appealing, but I think that there are some issues with how this is negotiated.

I've raised a few issues on your repo, but I think that the big one worth highlighting is the multi-hop one.  Bottom like is that I think that the Datagram-Flow-Id as a header field is problematic unless you also have a way to be sure that the connection you attempt this on supports the use of DATAGRAM frames specifically for CONNECT-UDP (not just each mechanism independently; that turns out to be disastrous if you have the right configuration).

That probably means that a separate setting is necessary in order to unlock this capability.

Cheers,
Martin

On Fri, Apr 17, 2020, at 13:01, David Schinazi wrote:
> -- 
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Mike Bishop <[email-masked]>
Date: Fri, 17 Apr 2020 18:09:50 +0000

I agree that this is a good general formulation.  Minor nits that stand out to me:

  *   Delimiting things with a blank line is very HTTP/1.1-specific.  Perhaps just rely on each HTTP version to define its own delimiting, and say that the payload consists of encoded datagrams as defined in Section 4.
  *   It’s not possible to detect that a connection has closed in UDP.  I would suggest either a timeout-based approach or one which simply says that the server MAY close the connection if needed.
  *   The client has no way to directly check H3D support on further-upstream hops, and assuming that a single flow ID can be used across all connections seems problematic.  Rather, state how datagrams to be sent are encoded on an individual hop; the server is responsible for choosing the most applicable way to pass the datagrams upstream, which might include sending its own CONNECT_UDP request with its own Flow ID.  The sequence of UDP datagrams might use DATAGRAM frames or the length-prefixed encoding on different hops, and that’s okay.

From: Masque <[email-masked]> On Behalf Of David Schinazi
Sent: Thursday, April 16, 2020 11:01 PM
To: MASQUE <[email-masked]>
Subject: [Masque] A proposal for CONNECT-UDP

Hi MASQUE enthusiasts,

framework. draft-schinazi-masque-protocol-01<https://tools.ietf.org/html/draft-schinazi-masque-protocol-01> goes into
Method: draft-schinazi-masque-connect-udp<https://tools.ietf.org/html/draft-schinazi-masque-connect-udp>

Thanks,
David Schinazi