Re: [Masque] Call for MASQUE use cases

[Mirja Kuehlewind <[e-mail]>]

To add more: The QUIC as a substrate draft (https://datatracker.ietf.org/doc/draft-kuehlewind-quic-substrate/) describes multiple potential use cases. We are most interested in the case where a proxy in the access network (e.g. mobile networks) could either assist the endpoint with additional information about the (mobile) link or enable different congestion control on the tunnel connection between the client and the proxy that covers the mobile link only. As the characteristics of cellular links are often different than for rest of path on the Internet, congestion control and recovery could be optimized differently for that link segment in order to use the mobile network capacity most efficiently.

Mirja


From: Masque <[e-mail]> on behalf of Eric Kinnear <ekinnear=[e-mail]>
Date: Monday, 9. March 2020 at 21:25
To: Dragana Damjanovic <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, MASQUE <[e-mail]>, Ben Schwartz <bemasc=[e-mail]>, Spencer Dawkins at IETF <[e-mail]>, Lucas Pardue <[e-mail]>, David Schinazi <[e-mail]>, Christopher Wood <[e-mail]>
Subject: Re: [Masque] Call for MASQUE use cases

Continuing the trend of use cases for this, we’ve got several in which we’d really like to have much better support for proxying of datagram flows, and MASQUE looks like it could be a really good start on a solution for those needs.

Thanks,
Eric



On Mar 7, 2020, at 4:51 AM, Dragana Damjanovic <[e-mail]<mailto:[e-mail]>> wrote:



On Fri, Mar 6, 2020 at 7:56 PM David Schinazi <[e-mail]<mailto:[e-mail]>> wrote:
Hi Dragana,

What's your use-case where the client has a set of IP address literals but no hostname?


The client has both.
The idea was to use DoH to resolve host name. Send IP address to a proxy and use ESNI (or what ever the new name might be). in this way you do not reveal host names you are connecting to to the proxy.

dragana

David

On Thu, Mar 5, 2020 at 10:00 PM Dragana Damjanovic <[e-mail]<mailto:[e-mail]>> wrote:


On Thu, Mar 5, 2020 at 3:19 PM Lucas Pardue <[e-mail]<mailto:[e-mail]>> wrote:


On Thu, Mar 5, 2020 at 2:05 PM Dragana Damjanovic <[e-mail]<mailto:[e-mail]>> wrote:

I was looking into implementing sending an IP address in CONNECT request to a proxy instead of host name. It is not easy to figure out if connect should be retried with another IP address.. Having better error codes would be helpful.

dragana

That's an interesting case. IIUC correctly, your client might ask the proxy to use IPv6, which could fail, and your client might then try IPv4?


yes. That would be most common case. We may retry a different ip address, but I am actually not sure how often is something like this happening because it may have a long delay depending on the netowrk error(try PIv4 address 1 and if it fails tray IPv4 address 2)

A failure such as this today would be communicated by returning an HTTP error status. Is there a gap that mean HTTP cannot be used to communicate the specific error condition you describe?

no, I think you cannot be 100% sure, the error may mean multiple things.


Thinking about it more, maybe it would be better to send a list of IP addresses and let proxy chose one or do a happy-eyeballing for example. That would mean a CONNECT with list of IP addresses instead of one or a host name..

dragana




Cheers
Lucas


--
Masque mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/masque
--
Masque mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/masque