Subject: [Masque] Comments on the proposed charter

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 16 Apr 2020 10:50:09 +0200

Hello,

Sorry for jumping late in the discussion. Based on Chris' github, the 
current charter text seems to be :

"The primary goal of this working group is to develop mechanisms that 
allow configuring and concurrently running multiple proxied stream- and 
datagram-based flows inside a HTTP/3 connection. The group will specify 
HTTP or HTTP/3 extensions to enable this functionality within an HTTP/3 
connection. The group will focus on a limited set of client-initiated 
services: (1) UDP CONNECT and then (2) IP proxying. Specifying proxy 
server discovery mechanisms is out of scope for the group. However, the 
group may specify techniques for identifying proxy servers to aid future 
discovery mechanisms."

I would like to echo the comments made by Mirja and Spencer and suggest 
that we do not restrict too much the scope of the WG. There are non-web 
use cases like ATSSS and similar types of services that could benefit 
from such an approach.

Looking at the discussion on HTTP CONNECT and the support for UDP, I 
would suggest to think broader than the current web use case. As we 
develop a new protocol, we should avoid introducting another 
ossification by limiting it to only support TCP and UDP. I would suggest 
to write the third sentence as follows:

"The group will focus on a limited set of client-initiated services: (1) 
extend CONNECT to support other transport protocols than TCP and then 
(2) IP proxying."

By indicating extend CONNECT, we leave the room for some small changes 
to the existing HTTP CONNECT if those are required (mapping TCP 
connections to a QUIC stream could be one example, indicating the 
willingness to listen to incoming connections could be another one).

By indicating "to support other transport protocols than TCP", we 
encourage the development of a generic solution that leaves room for 
SCTP and future transport protocols, even if the first version of the 
protocol would only support non-TCP flows as datagrams.

Best regards,

Olivier

---

From: Marcus Ihlar <[email-masked]>
Date: Thu, 16 Apr 2020 12:23:32 +0000

+1

Being able to map multiple end-to-end flows, both TCP and UDP, to different H3/QUIC streams within the same H3/QUIC connection without needing to do full IP proxying would be a very nice outcome of this work.
Using classic HTTP CONNECT for TCP would not allow that, if I understand things correctly.

BR
Marcus

-----Original Message-----
From: Masque <[email-masked]> On Behalf Of Olivier Bonaventure
Sent: den 16 april 2020 10:50
To: [email-masked]
Subject: [Masque] Comments on the proposed charter

Hello,

Sorry for jumping late in the discussion. Based on Chris' github, the current charter text seems to be :

"The primary goal of this working group is to develop mechanisms that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside a HTTP/3 connection. The group will specify HTTP or HTTP/3 extensions to enable this functionality within an HTTP/3 connection. The group will focus on a limited set of client-initiated
services: (1) UDP CONNECT and then (2) IP proxying. Specifying proxy server discovery mechanisms is out of scope for the group. However, the group may specify techniques for identifying proxy servers to aid future discovery mechanisms."

I would like to echo the comments made by Mirja and Spencer and suggest that we do not restrict too much the scope of the WG. There are non-web use cases like ATSSS and similar types of services that could benefit from such an approach.

Looking at the discussion on HTTP CONNECT and the support for UDP, I would suggest to think broader than the current web use case. As we develop a new protocol, we should avoid introducting another ossification by limiting it to only support TCP and UDP. I would suggest to write the third sentence as follows:

"The group will focus on a limited set of client-initiated services: (1) extend CONNECT to support other transport protocols than TCP and then
(2) IP proxying."

By indicating extend CONNECT, we leave the room for some small changes to the existing HTTP CONNECT if those are required (mapping TCP connections to a QUIC stream could be one example, indicating the willingness to listen to incoming connections could be another one).

By indicating "to support other transport protocols than TCP", we encourage the development of a generic solution that leaves room for SCTP and future transport protocols, even if the first version of the protocol would only support non-TCP flows as datagrams.

Best regards,

Olivier

--
Masque mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/masque

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Apr 2020 10:21:31 -0700

On Thu, Apr 16, 2020 at 5:23 AM Marcus Ihlar <marcus.ihlar=
[email-masked]> wrote:

> +1
>
> Being able to map multiple end-to-end flows, both TCP and UDP, to
> different H3/QUIC streams within the same H3/QUIC connection without
> needing to do full IP proxying would be a very nice outcome of this work.

As far as I know, it would. We presently do this for TCP with H2.

-Ekr

> that we do not restrict too much the scope of the WG. There are non-web use
> cases like ATSSS and similar types of services that could benefit from such
> an approach.
>
> Looking at the discussion on HTTP CONNECT and the support for UDP, I would
> suggest to think broader than the current web use case. As we develop a new
> protocol, we should avoid introducting another ossification by limiting it
> to only support TCP and UDP. I would suggest to write the third sentence as
> follows:
>
> By indicating extend CONNECT, we leave the room for some small changes to
> the existing HTTP CONNECT if those are required (mapping TCP connections to
> a QUIC stream could be one example, indicating the willingness to listen to
> incoming connections could be another one).
>
> encourage the development of a generic solution that leaves room for SCTP
> and future transport protocols, even if the first version of the protocol
> would only support non-TCP flows as datagrams.
>
> Best regards,
>
> Olivier
>
> --
> Masque mailing list
> [email-masked]

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 16 Apr 2020 21:29:41 +0100

Hi Olivier,

See my response below:

> protocol would only support non-TCP flows as datagrams.
I appreciate that is an admirable goal but in terms of scoping the work to
be achievable. Extending CONNECT to do one thing (UDP) is different to
extending CONNECT to do anything.

Building such a proxy requires it to decapsulate the inner protocol from
client packets and take all responsibility for setting up and maintaining
the hop to the origin. This is straightforward for TCP and UDP, and we have
confidence those transports are deployable on the Internet.

Transport "foo" would need to solve the origin hop problem, and be happy
with the reality of its success in traversing the neteork segment and
beyond. I don't know if there is a community out there that wants this and
is willing to do the work. And designing a CONNECT-anything for them seems
like a difficult thing to determine as "done". But maybe there's examples
of such proxies and what they want is a different frond-end?

In contrast, IP proxying if solved would shift burden for setting up and
maintaining state to the client. This is a generic solution that enables
many use cases without them becoming dependencies. And would allow a WG to
focus on challenges of IP tunneling, which seems like a more well bounded
set to me.

Cheers
Lucas

---

From: David Schinazi <[email-masked]>
Date: Thu, 16 Apr 2020 13:44:41 -0700

I'll note that the current charter is not focused on the Web use-case. It
contains text about proxying IP once we've figured out how to make UDP
work. There's also nothing in the charter precluding us from building
something that can be reused or extended for things like SCTP. Right now, I
haven't seen anyone propose a practical use-case where they need SCTP, so I
don't think we need that in the charter until then.

David

On Thu, Apr 16, 2020 at 1:30 PM Lucas Pardue <[email-masked]>
wrote:

> Olivier.Bonaventure@uclouvain..be <[email-masked]>>
> wrote:
>
>> Hello,
>>

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 17 Apr 2020 09:25:42 +0200

Lucas,

> I appreciate that is an admirable goal but in terms of scoping the work 
> to be achievable. Extending CONNECT to do one thing (UDP) is different 
> to extending CONNECT to do anything.
> 
> client packets and take all responsibility for setting up and 
> maintaining the hop to the origin. This is straightforward for TCP and 
> UDP, and we have confidence those transports are deployable on the 
> Internet.

I totally agree that supporting TCP and UDP is feasible from an 
implementation viewpoint and that supporting any protocol is potentially 
more complex. I'm not asking for a solution that does everything, but 
for a solution that is extensible and will be able to evolve in the 
future to prevent additional ossification.

Instead of having CONNECT and defining CONNECT_UDP with whatever 
parameters, I would argue to replace the CONNECT_UDP with something like
CONNECT_TRANSPORT that takes as parameter a protocol number or any 
identifier. In most current deployments, the protocol number would be 
UDP and initial implementations could return an error message when 
another protocol number is used, but at least we'd have something that 
is more future proof than a CONNECT_UDP
> beyond. I don't know if there is a community out there that wants this 
> and is willing to do the work. And designing a CONNECT-anything for them 
> seems like a difficult thing to determine as "done". But maybe there's 
> examples of such proxies and what they want is a different frond-end?
> 
> many use cases without them becoming dependencies. And would allow a WG 
> to focus on challenges of IP tunneling, which seems like a more well 
> bounded set to me.

IP proxying is an important part of the charter

Olivier

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 17 Apr 2020 11:09:54 +0100

Hey Olivier,

> is more future proof than a CONNECT_UDP

I think it's a false economy. The API is cheap to implement IMO, and we
have no shortage of method names that would allow CONNECT_XYZ. The
complexity comes on the proxy-to-origin side, and that's where people will
be conservative in implementing different transports. So I don't see how
encoding a value in a field, instead of the method name, solves
ossification.

Creating an extensibility mechanism that solves only the simplest of
challenges for the extension seems low value and has the downside of
creating yet another mechanism built into HTTP.

Cheers
Lucas