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

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
>