Re: [Masque] Call for MASQUE use cases

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Ben,

Thank you for the clues below.

Perhaps we should talk in Vancouver :-)

Best,

Spencer

On Mon, Feb 24, 2020 at 11:52 AM Ben Schwartz <[e-mail]> wrote:

>
>
> On Mon, Feb 24, 2020 at 11:57 AM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> Hi, Ben,
>>
>> I have a couple of questions about some use cases you described (inline),
>> but thank you for sending out your list.
>>
>> On Sun, Feb 23, 2020 at 10:06 PM Ben Schwartz <bemasc=
>> [e-mail]> wrote:
>>
>>> I think virtually all the use cases for SOCKS and HTTP CONNECT are also
>>> in-scope for MASQUE.  Additionally, there are some cases that they don't
>>> handle, or that MASQUE could handle better:
>>>
>>>  - TCP proxying over congested/lossy client-proxy links.  SOCKS and
>>> HTTP/1.1 don't multiplex, so the congestion controllers for each TCP
>>> connection fight over this link.  HTTP/2 multiplexes but has head-of-line
>>> blocking on loss.  CONNECT over HTTP/3 would get us unified
>>> congestion control without blocking.
>>>
>>
>> IIRC, CONNECT currently doesn't know how to do HTTP/3 over QUIC, right?
>> So is what you're thinking about
>>
>>    - Connect can do HTTP/3 - proxy - HTTP/3 or HTTP/2 - proxy - HTTP/2,
>>    OR
>>    - Connect can do HTTP - proxy - HTTP, where the HTTP versions don't
>>    have to match?
>>
>> I am trying to describe this: client <--[H3]---> proxy <--[SSH]-->
> destination
>
> Where "SSH" is an arbitrary example of a TCP-based protocol.  Any TCP
> connection can run over CONNECT.
>
> In other words, I am talking about unmodified CONNECT over HTTP/3.
>
>  - Proxied WebRTC (or RTC generally).  Currently, using a proxy generally
>> forces WebRTC to use TCP, which generally also forces it to route through a
>> TURN server (another proxy!).  This adds up to significantly impaired
>> latency and quality.  By supporting UDP, MASQUE could do better.
>>
>>>
>>> - Virtual machine running in a webpage.  MASQUE could enable
>>> standardized networking for virtual machines in WebAssembly.
>>>
>>> - Network debugging when using a proxy.  HTTP CONNECT doesn't provide
>>> any indication of why a connection failed, e.g. to distinguish RST, FIN,
>>> timeout, or an ICMP error.
>>>
>>
>> We've come some distance since I was introducing myself at IESG meetings
>> as "AD for the spin bit", but we haven't come a really long way - the spin
>> bit is in and optional, which is fine, and we are noticing
>> https://datatracker.ietf.org/doc/draft-ferrieuxhamchaoui-quic-lossbits/
>> as a related draft, but we haven't had it on a QUIC working group agenda in
>> the past year (IIRC), even though it gets talked about in places like MOPS.
>> And that's just one more (almost certainly optional) bit of information, if
>> it does move forward.
>>
>> I'm intrigued by your proposed use case on network debugging, especially
>> if proxying HTTP/3 using CONNECT becomes a common mode of operation - have
>> you started to hash out details for this use case, what might be visible
>> without revealing too much, etc.? If not, would you like to work on
>> something with me (and, one hopes, smarter and more realistic QUIC people)?
>>
>
> I wasn't really thinking about QUIC; I was thinking primarily about TCP.
> If we're in the business of modernizing CONNECT, one thing that I would
> like would be an HTTP Trailer indicating _why_ the connection was closed,
> e.g. who closed it, FIN vs. RST vs. timeout.  Similarly, if CONNECT fails,
> it would be nice to have a header indicating why it failed, and perhaps
> some clarity about which status codes to use.  My main use case here is
> "showing users the right error message" when something goes wrong.
>
> I would have to think some more about QUIC.  In my view, it depends on
> whether we end up defining (1) a QUIC-specialized proxy, (2) a general UDP
> transport proxy, and/or (3) an IP tunnel.  If (1) or (2), it could be
> interesting to consider how to convey some lower-layer information to
> enable ICMP error reporting, PMTUD, etc.  (An IP tunnel gets us all that
> stuff automatically.)
>
> One thing I have proposed is using continuous measurement of client-proxy
> RTT to unify the two layers of congestion control, but this is a purely
> hypothetical performance optimization, not for network debugging.
>
>
>> Best,
>>
>> Spencer
>>
>>
>>> On Sat, Feb 22, 2020 at 6:14 PM Eric Rescorla <[e-mail]> wrote:
>>>
>>>> I am interested in this as an alternative transport for securely
>>>> proxying HTTP traffic (cf. https://fpn.firefox.com/)
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> On Thu, Feb 20, 2020 at 7:13 PM Christopher Wood <[e-mail]>
>>>> wrote:
>>>>
>>>>> The core MASQUE protocol [1] describes a simple negotiation mechanism
>>>>> for various
>>>>> applications. However, it omits use cases for these applications.
>>>>> MASQUE
>>>>> obfuscation
>>>>> in support of a "hidden VPN" service is one use case [2]. Tunneling
>>>>> QUIC
>>>>> is another [3].
>>>>>
>>>>> Given that MASQUE and the upcoming BoF will be successful insofar as
>>>>> it
>>>>> addresses important
>>>>> use cases, I think it'd be useful to discuss these application use
>>>>> cases
>>>>> in more detail
>>>>> before Vancouver. To that end, let's use this time before the meeting
>>>>> to
>>>>> discuss them!
>>>>>
>>>>> I'd like to ask interested parties to please surface use cases they
>>>>> know
>>>>> of (and care about).
>>>>>
>>>>> Thanks!
>>>>> Chris
>>>>>
>>>>> [1] https://tools.ietf.org/html/draft-schinazi-masque-02
>>>>> [2] https://tools.ietf.org/html/draft-schinazi-masque-obfuscation-00
>>>>> [3] https://tools.ietf.org/html/draft-kuehlewind-quic-substrate-02
>>>>>
>>>>> --
>>>>> Masque mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/masque
>>>>>
>>>> --
>>>> Masque mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/masque
>>>>
>>> --
>>> Masque mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/masque
>>>
>> --
>> Masque mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/masque
>>
>