Re: [Masque] Dropping HTTP/1.x requirement for CONNECT-UDP

[Mirja Kuehlewind <[e-mail]>]

I agree. I thought that the mapping is actually relatively straight forward though. With H2 you can have one CONNECT per stream (and no datagram support). For H1 you can only have one CONNECT per connection and you would open multiple TCP/HTTP connections for each forwarding request separately.



From: Masque <[e-mail]> on behalf of Alex Chernyakhovsky <achernya=[e-mail]>
Date: Wednesday, 24. March 2021 at 02:11
To: Ian Swett <[e-mail]>
Cc: David Schinazi <[e-mail]>, Mark Nottingham <[e-mail]>, Roy Fielding <[e-mail]>, Tommy Pauly <[e-mail]>, MASQUE <[e-mail]>
Subject: Re: [Masque] Dropping HTTP/1.x requirement for CONNECT-UDP

I don't think aligning h1 and h2 makes sense. h2 is closer to h3 than it is to h1.

Sincerely,
-Alex

On Tue, Mar 23, 2021 at 7:25 PM Ian Swett <[e-mail]<mailto:[e-mail]>> wrote:
IMO it makes sense to align the h1 and h2 designs, since they're both fallbacks we'd rather not use.  If h1+h2 lands after h3 in a different doc, I don't see a problem with that, but I'm also fine with them being in a single document.

In a surprising number of cases where h3 is blocked, h2 is blocked as well(ie: Corp MITMs) and users will end up on h1.  Additionally, h1 is still widely used behind load balancers/proxies.  As such, by the time this becomes RFC, I wouldn't be surprised if there's more usage of it over h1 than h2.

I don't think the CONNECT-UDP design for h2 and h3 needs to share framing, given h3 has datagrams and doesn't need frames transmitted on streams to transmit UDP?

On Tue, Mar 23, 2021 at 6:42 PM David Schinazi <[e-mail]<mailto:[e-mail]>> wrote:
Or we could have one document now that describes CONNECT-UDP over h2 and h3, and a separate document that defines CONNECT-UDP over h1 later?
I'm not saying CONNECT-UDP should never support HTTP/1.1, I'm just saying that maybe we don't need to design that yet.

Thoughts?
David

On Mon, Mar 22, 2021 at 7:57 PM Tommy Pauly <[e-mail]<mailto:[e-mail]>> wrote:
Yes, that’s what I recall as well.

David, can we still go down the path of using frames in HTTP/3 and HTTP/2, while letting CONNECT-UDP have a more degenerate case for HTTP/1.1?

Tommy

> On Mar 22, 2021, at 7:53 PM, Mark Nottingham <[e-mail]<mailto:[e-mail]>> wrote:
>
> My recollection is that this was discussed at length during chartering, and the resolution was that we'd make it version-independent, like other methods. If you want to re-visit that, I think we'd need to ask the whole HTTP WG, not just a couple of people.
>
> Cheers,
>
>
>> On 23 Mar 2021, at 9:39 am, Tommy Pauly <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> While I understand the desire for this, I’m concerned about making a method that only works with some versions.
>>
>> From https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#methods<https://protect2.fireeye.com/v1/url?k=57aa9374-0831aa71-57aad3ef-86d2114eab2f-8a67a28437e1dc6d&q=1&e=cd2d81ff-d165-41ed-836c-128d76921781&u=https%3A%2F%2Fhttpwg.org%2Fhttp-core%2Fdraft-ietf-httpbis-semantics-latest.html%23methods> :
>>
>> HTTP defines a number of generic extension points that can be used to introduce capabilities to the protocol without introducing a new version, including methods, status codes, field names, and further extensibility points within defined fields, such as authentication schemes and cache-directives (see Cache-Control extensions in Section 5.2.3 of [Caching]). Because the semantics of HTTP are not versioned, these extension points are persistent; the version of the protocol in use does not affect their semantics.
>>
>> Version-independent extensions are discouraged from depending on or interacting with the specific version of the protocol in use. When this is unavoidable, careful consideration needs to be given to how the extension can interoperate across versions.
>>
>> I’d like to hear the opinions of Mark and Roy on this.
>>
>> Tommy
>>
>>> On Mar 22, 2021, at 3:21 PM, Alex Chernyakhovsky <achernya=[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>> I think this makes a lot of sense. As it stands today, anyone wishing to add UDP support would have to make changes to their client/server anyway -- I feel like the complexity we'd take on by continuing to support HTTP/1.1 and older isn't beneficial since we wouldn't be able to interoperate with existing implementations with the new features. Requiring HTTP/2 or newer lets us rely on a lot of nice things that have been added (like multiplexing) and not have to re-invent them in HTTP/1.1 just for UDP.
>>>
>>> Sincerely,
>>> -Alex
>>>
>>> On Thu, Mar 18, 2021 at 6:12 PM David Schinazi <[e-mail]<mailto:[e-mail]>> wrote:
>>> Hi MASQUE enthusiasts,
>>>
>>> The CONNECT-UDP draft currently states "The CONNECT-UDP method is defined for all versions of HTTP." While supporting HTTP/3 is our top priority, and supporting HTTP/2 is necessary because of networks that block UDP, I'm not sure supporting versions of HTTP before 2 is useful. Additionally, it constrains our design space as HTTP/1.1 does not have the HTTP framing layer that HTTP/2 and HTTP/3 have. I would like to drop support for HTTP/1.1, 1.0 and 0.9.
>>>
>>> Does anyone object to dropping the requirement to support versions of HTTP before 2?
>>>
>>> Thanks,
>>> David
>>> --
>>> 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
>>
>
> --
> Mark Nottingham   https://www.mnot.net/<https://protect2.fireeye.com/v1/url?k=0c525adb-53c963de-0c521a40-86d2114eab2f-69a3e42f0cf4ffba&q=1&e=cd2d81ff-d165-41ed-836c-128d76921781&u=https%3A%2F%2Fwww.mnot.net%2F>
>
> --
> 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