Re: [Webtransport] Confirming consensus calls from today's WebTransport interim

David Schinazi <dschinazi.ietf@gmail.com> Thu, 03 June 2021 16:28 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: webtransport@ietfa.amsl.com
Delivered-To: webtransport@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96E73A0CDA for <webtransport@ietfa.amsl.com>; Thu, 3 Jun 2021 09:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfOKrA0e9bNU for <webtransport@ietfa.amsl.com>; Thu, 3 Jun 2021 09:28:38 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305723A0CD5 for <webtransport@ietf.org>; Thu, 3 Jun 2021 09:28:38 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id c13so3187858plz.0 for <webtransport@ietf.org>; Thu, 03 Jun 2021 09:28:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mHcZZyTEvTa/9E/d4sEFrQEDltGyhjTeFw3yhPzNz5c=; b=ZSE7VgIZFkSYrU37VIvwBsRZIA6+bwb8KCNJVVFBDBbNYluJoQ2Tprs1Vf+4rCXo51 NPpL6szEYlzjCwLZGfCXMziIDHuE1NbU7yC1+qyWqSA1z55GfloHaG4+Ser4UcYOaqZg 8Cdol8ivDVeFzlX5hGMIAKGBJCHGpgTXPKOICwY1kC3D03ehA8QwJskYc96MvBIVHsd4 c4bLt5JQQPdzevZY6XmerOKDzXn2nJtH0TDnKls1fLCTv6YEVuHAqfITeFi4ClU0eO+E wVEarOOgQk96B/NaTdbfvoqsPOTdASvsQ16m3vHHGgwUJ05Ncx2vzn1dhJPxgPtvofXs B2nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mHcZZyTEvTa/9E/d4sEFrQEDltGyhjTeFw3yhPzNz5c=; b=LIAZ2lKAEjw8YmJ2dpJo+XoyPTdILURceqcTiMd/ubuxtt9EglWnmzQdU42PjkoiRl PyFae42qCqmECIselAK8DOz41emFJ/6xq59u7LLDhUZ4zHWTbMMxOie1VlGUESe8+gfY HxDTRBjrxt3z2L4ZuIoDBwA1CtgCj2TI0LnEn1OtlMvRf5qixedREDgAyd1PuvMKnw9O jYmfzqX8a9dfL8jdovnuaayRklBEKeDgVW5JRT6Ds0Fw+mqaiXTCyGUnVRW2oE24UHK9 gpa80O9nw4zSqlc/8kFNIXmNUB5DePsyBUIdikArcJ4gFlIw9KdIg7XDsmk3BxmeYwnD HmMA==
X-Gm-Message-State: AOAM531/8ynmlCpH7cm3JYfjmwjDi9FmTep2XxR0HfAHPBj1vJm7SoX1 B0UmhE7aJqrFTt63vbhzElK13V8d0xt62xBwXZk=
X-Google-Smtp-Source: ABdhPJyYf6Z0PoZzdrALFl/Mhb6+EMA1AYkv+3tRXVVkHpl8z2yi7QewdiaEoG4l7MIZJQOdSbdPyu0Ihtz+NQGQT04=
X-Received: by 2002:a17:902:a5c9:b029:f7:9f7e:aa2f with SMTP id t9-20020a170902a5c9b02900f79f7eaa2fmr315415plq.54.1622737716238; Thu, 03 Jun 2021 09:28:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAPDSy+5s-D7v3jxFmWKD5N-=sVcM_v8ZmB1iVNjZ1ZuHN5n=OQ@mail.gmail.com> <cce29e58-da55-4cc1-b760-4ee1c849c035@www.fastmail.com> <CAAZdMad9hZMutYAWQOO=T+UtV9tuMreHy707JO6qN40k2SVmMQ@mail.gmail.com> <69e2d8c9-b532-4ce3-b558-9fdd11e5fb1a@www.fastmail.com> <304A9399-D211-4463-9245-C2437E318FC3@fb.com> <CAKcm_gOLTXtjf_jQWZ12sKe4L-e5J3jA+Zn5zjd7UJrVYQ1f8w@mail.gmail.com> <CAPDSy+7hBj8EAJcydCGb5iVh3XxFoaBLzKgb=4X7myP-2-ZEZA@mail.gmail.com> <CAKcm_gNnQM5i7hR3V48ETnKX=WiizK7Z27w=cb3N_qLGdoB0LA@mail.gmail.com>
In-Reply-To: <CAKcm_gNnQM5i7hR3V48ETnKX=WiizK7Z27w=cb3N_qLGdoB0LA@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 03 Jun 2021 09:28:24 -0700
Message-ID: <CAPDSy+5V8YhXVjCw1U4KcCcC+pzXZ7dBPJoYNDojEdACfnrO2Q@mail.gmail.com>
To: Ian Swett <ianswett@google.com>
Cc: Alan Frindell <afrind@fb.com>, Victor Vasiliev <vasilvv@google.com>, WebTransport <webtransport@ietf.org>, Martin Thomson <mt@lowentropy.net>
Content-Type: multipart/alternative; boundary="00000000000023db9705c3df11f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/_OtzswEFNrWOwslTsV0Fa-xsSUM>
Subject: Re: [Webtransport] Confirming consensus calls from today's WebTransport interim
X-BeenThere: webtransport@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <webtransport.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webtransport>, <mailto:webtransport-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webtransport/>
List-Post: <mailto:webtransport@ietf.org>
List-Help: <mailto:webtransport-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webtransport>, <mailto:webtransport-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 16:28:44 -0000

Can you provide an example of a network that would benefit from this scope
increase? I've yet to see a network that MITMs TLS but allows all HTTP/1.1
through unmodified. The ones that MITM and downgrade to h1 generally do it
because they then inspect and/or modify the request and response, so
getting something with WebTransport semantics to work there at all isn't
guaranteed to be possible. Perhaps a good step forward is for us to build a
version of WebTransport over h2 and then look at deployment data and
feedback to decide if another version is needed.

David

On Thu, Jun 3, 2021 at 8:56 AM Ian Swett <ianswett@google.com> wrote:

>
>
> On Thu, Jun 3, 2021 at 11:38 AM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>> Hi Ian,
>>
>> Can you elaborate on what use-case would be solved by having WebTransport
>> support HTTP/1 ?
>> - We know there are networks that block QUIC and/or UDP, those will be
>> well served by HTTP/2.
>> - We know there are networks that MITM TLS then force a transparent
>> HTTP/1 proxy, those won't allow CONNECT nor any other form of WebTransport
>> anyway.
>> I'm failing to see a use-case where WebTransport over HTTP/1 would be
>> useful. Can you provide an example?
>>
>
> I think there's evidence that those two sets of networks are very similar
> today, and over time I expect the set of networks that block QUIC but don't
> block HTTP/2 to be tiny(ie: <1%).
>
> But I could be wrong.
>
>>
>> Thanks,
>> David
>>
>> On Thu, Jun 3, 2021 at 6:57 AM Ian Swett <ianswett=
>> 40google.com@dmarc.ietf.org> wrote:
>>
>>> I definitely agree with 1a, with the caveat that the TCP version is
>>> lower priority than the HTTP/3 version.
>>>
>>> I'm slightly less concerned about the stream state machine than Martin,
>>> but I think it's definitely a real concern and I think it makes sense to
>>> have a solution fairly well fleshed out before adopting the direction and
>>> document.
>>>
>>> I'm slightly more concerned about creating a TCP fallback that doesn't
>>> work over HTTP/1.  If we're building a fallback, it seems like these people
>>> shouldn't be excluded, since that means developers will have to build and
>>> maintain a 3rd fallback that's not WebTransport based.  If the dream is to
>>> be able to develop apps for WebTransport and not have a non-WebTransport
>>> fallback, I don't see how we accomplish that without an option over HTTP/1?
>>>
>>> Possibly this is a forcing function to convince customers to upgrade
>>> their middleboxes to ones which support HTTP/2 and HTTP/3, but if so I'd
>>> like to call that out explicitly.
>>>
>>> Or maybe the physical office with its corp middleboxes is dead and my
>>> concern is an unfounded anachronism?
>>>
>>> Ian
>>>
>>> On Tue, May 25, 2021 at 5:36 PM Alan Frindell <afrind=
>>> 40fb.com@dmarc.ietf.org> wrote:
>>>
>>>> I think the fundamental discussion here is about whether we want to
>>>> modify/extend the HTTP/2 state machine to handle WebTransport streams, or
>>>> whether we should build an entirely separate stream state machine for them,
>>>> and leave the H2 machinery untouched.
>>>>
>>>> Martin may be right that there be dragons down the path of modifying
>>>> the H2 state machine.  The alternative strikes me as an awful lot of
>>>> duplication -- it's close to implementing H2 again over a single HTTP
>>>> stream, minus header processing.  That said, I think either approach can be
>>>> made to work, we just need to choose the tradeoffs we want.
>>>>
>>>> I am remiss in not addressing the feedback regarding unidirectional
>>>> stream resets.  I think that it got lost during the bizarre hours of the
>>>> last IETF.  I filed an issue in the draft repo to track it (
>>>> https://github.com/ekinnear/draft-webtransport-http2/issues/17).  I
>>>> think the right solution is to keep the unidirectional reset functionality,
>>>> and implement it in the H2 draft using either new frames or messages,
>>>> depending on the direction we take regarding the state machine.
>>>>
>>>> During the interim, we expressed our flexibility to adapt the design
>>>> here as the H3 design evolves (eg: stream limits), new tools become
>>>> available (eg: CAPSULE) and as we gather implementation experience.
>>>>
>>>> While I think it is important we address this design decision as soon
>>>> as possible, I don't know that it needs to block adoption.
>>>>
>>>> Thanks
>>>>
>>>> -Alan
>>>>
>>>> On 5/23/21, 6:48 PM, "Webtransport on behalf of Martin Thomson" <
>>>> webtransport-bounces@ietf.org on behalf of mt@lowentropy.net> wrote:
>>>>
>>>>     On Sat, May 22, 2021, at 02:06, Victor Vasiliev wrote:
>>>>     > On Thu, May 20, 2021 at 9:37 PM Martin Thomson <mt@lowentropy.net>
>>>> wrote:
>>>>     > > I'm opposed to adoption of this document.  I don't believe that
>>>> it can be made so due to some fundamental differences in how HTTP/2 and
>>>> QUIC stream states.
>>>>     > >
>>>>     > > If this problem was acknowledged, then I have every confidence
>>>> that the people listed as authors are able to find a solution.  But
>>>> generally adoption is about the document more than the people.  Adoption
>>>> means agreeing that the document contains approximately the right shape for
>>>> a solution.  I can't agree with that in this case.
>>>>     >
>>>>     > Hi Martin,
>>>>     >
>>>>     > Could you elaborate on the specific differences between HTTP/2
>>>> and QUIC
>>>>     > stream state machines that you are concerned about?  The only one
>>>> I am
>>>>     > aware of is unidirectional versus bidirectional reset, and last
>>>> time we
>>>>     > discussed this, the easiest solution was to make HTTP/3 behave
>>>> like
>>>>     > HTTP/2, which would mean there's nothing HTTP/2 draft would do to
>>>>     > address that.
>>>>
>>>>     That's the one I'm most concerned about, but there is also the
>>>> whole mess around inventing semantics for unidirectional streams that needs
>>>> to be worked into the state machines.
>>>>
>>>>     For reset, sure, you could make the HTTP/3 draft worse to deal with
>>>> the problem.  Why would you want that?  QUIC has a much better set of
>>>> semantics here than HTTP/2.
>>>>
>>>>     There is also the stream state management disconnect for
>>>> server-initiated streams, which currently is only used for server push.
>>>> The draft currently doesn't say anywhere near as much as it would need to
>>>> in order to specify that part.
>>>>
>>>>     And managing allocation of stream limits is a little scant on
>>>> detail in the same way.  I thought we wanted independent limits, which
>>>> means defining new accounting systems.  (Yes, this is a criticism of the
>>>> HTTP/3 draft also, but the additional effort required to use QUIC streams
>>>> is entirely justified in that case, because you are getting something in
>>>> exchange.)
>>>>
>>>>     Why bother with all of that when you can just import QUIC frame
>>>> semantics and then serialize them on the same stream?
>>>>
>>>>     Yes, this all boils down to a fairly central question: do we build
>>>> the same thing for HTTP/2 and HTTP/3?  I'm not sure that we want that.  We
>>>> need to do a whole bunch of stuff to use QUIC (BTW, Roberto gets to say
>>>> "told you so" again here), but doing that same work for HTTP/2 doesn't make
>>>> sense unless the changes are minimal.  I'm suggesting that the changes
>>>> aren't as minimal as the rough sketches of protocols we have might imply.
>>>>
>>>>     If you conclude that there are more functions needed, as I have
>>>> done, then you might also conclude that building those same functions into
>>>> two different protocols is not desirable, especially when there are no
>>>> benefits to doing so for one of those protocols.
>>>>
>>>>     --
>>>>     Webtransport mailing list
>>>>     Webtransport@ietf.org
>>>>     https://www.ietf.org/mailman/listinfo/webtransport
>>>>
>>>> --
>>>> Webtransport mailing list
>>>> Webtransport@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>>
>>> --
>>> Webtransport mailing list
>>> Webtransport@ietf.org
>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>
>>