Re: [Masque] Call for MASQUE use cases

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

Hi, Ted,

On Mon, Feb 24, 2020 at 11:20 AM Ted Hardie <[e-mail]> wrote:

> In-line.
>
> Ted
>
> On Mon, Feb 24, 2020 at 8: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?
>>
>>  - 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),
>>
> It was the last item discussed at the last interim, see the minutes here:
> https://github.com/quicwg/wg-materials/blob/master/interim-20-02/minutes.md
>

Thank you for this pointer! The minutes were posted to the datatracker, but
I wasn't checking interim meeting minutes. My bad.


> regards,
>
> Ted Hardie
>
>
>> 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.
>>
>
Of course, it's still only one more bit of information :-)

So, I'm still intrigued by Ben's suggestion.

Best,

Spencer


>
>> 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)?
>>
>> 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
>>
>