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

> On Mar 25, 2021, at 12:56 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Dear All, 
> 
> On Thu, Mar 25, 2021 at 1:55 PM Ian Swett <ianswett@google.com <mailto: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?

That was the original question, but my sense of this thread (which I agree with) is that all versions ought to be specified at the same time. HTTP versions are often used back-to-back as communication traverses intermediaries, and any solution that leaves out some versions, even only temporarily, is not fully-fledged.

Best,
Tommy

> 
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto:masque-bounces@ietf.org>> on behalf of Alex Chernyakhovsky <achernya=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>>
> Date: Wednesday, 24. March 2021 at 02:11
> To: Ian Swett <ianswett@google.com <mailto:ianswett@google.com>>
> Cc: David Schinazi <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>>, Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net>>, Roy Fielding <fielding@gbiv.com <mailto:fielding@gbiv.com>>, Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>>, MASQUE <masque@ietf.org <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:Masque@ietf.org>
> >>> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> >>> -- 
> >>> Masque mailing list
> >>> Masque@ietf.org <mailto:Masque@ietf.org>
> >>> https://www.ietf.org/mailman/listinfo/masque <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 <mailto:Masque@ietf.org>
> > https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> -- 
> Masque mailing list
> Masque@ietf.org <mailto:Masque@ietf.org>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>-- 
> Masque mailing list
> Masque@ietf.org <mailto:Masque@ietf.org>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> -- 
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque