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

Dear All,

On Thu, Mar 25, 2021 at 1:55 PM Ian Swett <ianswett@google.com> wrote:

> I agree that I think we need all 3 versions and didn't intend my message
> to indicate that an h2 version shouldn't be created, but rather that I
> expect an h1 may be used quite widely.
>

Thanks for helping me understand. I was curious because I thought I saw
some people suggesting that it would be helpful to do the h2 and h3
mappings first, and h1 mapping later, and other people saying that h1
mapping mattered a lot.

If we have to do all three, do we need to do all three at the same time?

Best,

Spencer

> In terms of MITMs, David Schinazi pointed out that MITMs which block QUIC
> may also block CONNECT-UDP, and time will tell on that.
>
>
>
> On Thu, Mar 25, 2021 at 2:14 PM Alex Chernyakhovsky <achernya@google.com>
> wrote:
>
>> Hi Spencer,
>>
>> Can you please double-check if if all the instances of h1, h2, h3 you
>> wrote are correct? I'm having trouble parsing your message.
>>
>> I also want to add that I don't think restricting ourselves to h1 if h3
>> fails makes much sense. h2 has benefits, and IMO we should use them over h1
>> if h3 is unavailable.
>>
>> Sincerely,
>> -Alex
>>
>>
>> On Thu, Mar 25, 2021 at 10:06 AM Spencer Dawkins at IETF <
>> spencerdawkins.ietf@gmail.com> wrote:
>>
>>> I'm actually following up on something Ian said earlier ...
>>>
>>> On Thu, Mar 25, 2021 at 8:42 AM Mirja Kuehlewind <mirja.kuehlewind=
>>> 40ericsson.com@dmarc.ietf.org> wrote:
>>>
>>>> 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 <masque-bounces@ietf.org> on behalf of Alex
>>>> Chernyakhovsky <achernya=40google.com@dmarc.ietf.org>
>>>> *Date: *Wednesday, 24. March 2021 at 02:11
>>>> *To: *Ian Swett <ianswett@google.com>
>>>> *Cc: *David Schinazi <dschinazi.ietf@gmail.com>, Mark Nottingham <
>>>> mnot@mnot.net>, Roy Fielding <fielding@gbiv.com>, Tommy Pauly <
>>>> tpauly@apple.com>, MASQUE <masque@ietf.org>
>>>> *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 <ianswett@google.com> 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 know there's a conceptual reason for having mappings for h3, h2, and
>>> h1, but if Ian's experience here is typical, how bad would it be if the
>>> recommendation was to fall back from h3 to h1?
>>>
>>> If h2 doesn't work on a path now, do we want to encourage those
>>> operators to allow h2 and continue to block h3, rather than encouraging
>>> people to allow h3?
>>>
>>> Best,
>>>
>>> Spencer
>>>
>>>>
>>>>
>>>> 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 <
>>>> dschinazi.ietf@gmail.com> 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 <tpauly@apple.com> 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 <mnot@mnot.net> 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 <tpauly@apple.com> 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=
>>>> 40google.com@dmarc.ietf.org> 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 <
>>>> dschinazi.ietf@gmail.com> 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
>>>> >>> Masque@ietf.org
>>>> >>> https://www.ietf.org/mailman/listinfo/masque
>>>> >>> --
>>>> >>> Masque mailing list
>>>> >>> Masque@ietf.org
>>>> >>> 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
>>>> > Masque@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/masque
>>>>
>>>> --
>>>> Masque mailing list
>>>> Masque@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/masque
>>>>
>>>> --
>>>> Masque mailing list
>>>> Masque@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/masque
>>>>
>>>