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

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