Re: [Webtransport] Confirming consensus calls from today's WebTransport interim
Ian Swett <ianswett@google.com> Thu, 03 June 2021 15:56 UTC
Return-Path: <ianswett@google.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 DC1223A0772 for <webtransport@ietfa.amsl.com>; Thu, 3 Jun 2021 08:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 zfOfrCNh2kwH for <webtransport@ietfa.amsl.com>; Thu, 3 Jun 2021 08:56:30 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 A65383A0765 for <webtransport@ietf.org>; Thu, 3 Jun 2021 08:56:29 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id i94so1336769wri.4 for <webtransport@ietf.org>; Thu, 03 Jun 2021 08:56:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xVrQedFkMjR8Er27wwSzcrx7vpSZwP6tIkioKWfzuvs=; b=rm3KOgMMwMdid9XG0An9r8PHwaFdJ3ObA6y2HfeAsAMToCkxdn2JtLHJjLu05XtFYx OElbBgbhBx71ZFnicY1CvPmsZh0GGpgdcUrtsuUT+EIeuKD5ZyxZI7LqGQ5YDrhVEdrY Nkk6GSdqX/TN0+jguk40CXt0nSH0q7E+Gd0b82PBTkChYxm5DGD+m99gGg/TrWyq0BYN O8NQzFvn7bVgL0bHaVsv6CDGszVB69bx7W/yKP0HjNtNS2JoquCG0MrlJVuGZrRevcWM XzqSSDAlP/lSLZMJo6Te+ik54kv2q391BpmTo+O674HsZ9MQpgE3M4l6aIBhhwL5gh5k fnhQ==
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=xVrQedFkMjR8Er27wwSzcrx7vpSZwP6tIkioKWfzuvs=; b=un2zgi1asK609fYSspEQvWsM7lx4o6D9gFF/gtcmbg4xZTiQ6fJzWCd2By0/fTulGp fggxmrHywAPe0jxPxU4VhbDDwKc+geoUlgxrdqbn59XBFbFasm4fnvozTqKH25newHeW 1rSKiil3SktYEcsAAX3zEAu+85rvXy9EOEQpgdlg5FVHtNrH7d6JUR7sZI/1CxP7yEsC qdNr/LTNNfLkV2ozSe1w330dniKuPynf6NUeXXiXQGkH0qKrVTphsuVuvqiSb0efiU8k vzkpAlygTqiOvJ5Me0fpawV3dFS+vqdT6SukkVFYyWCgRH/VIayHRODKdC4Ycvs6VkoZ a7GA==
X-Gm-Message-State: AOAM532VCp6Cesg1hH+C6yW9JUXmZqTI0Gr7V7o/PCzfSiPlJXyb06JR Vl8BBb1ySwjt5FvUjlueYeeZsH0bSE5HUPLazfJ7ww==
X-Google-Smtp-Source: ABdhPJzuohgwePCWTeflIBGgPR2XQwpAxT+APb4JkRYH0ffII1Qy8YCRNvrBRieH+fmYafc2Y16jyfxSf74j2VE7Aio=
X-Received: by 2002:adf:f90c:: with SMTP id b12mr634090wrr.409.1622735786246; Thu, 03 Jun 2021 08:56:26 -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>
In-Reply-To: <CAPDSy+7hBj8EAJcydCGb5iVh3XxFoaBLzKgb=4X7myP-2-ZEZA@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Thu, 03 Jun 2021 11:56:14 -0400
Message-ID: <CAKcm_gNnQM5i7hR3V48ETnKX=WiizK7Z27w=cb3N_qLGdoB0LA@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.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="0000000000001acf3605c3de9eca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/eTlKaDjlUtupiIcStE7frokLe5g>
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 15:56:36 -0000
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 >> >
- [Webtransport] Confirming consensus calls from to… David Schinazi
- Re: [Webtransport] Confirming consensus calls fro… Bernard Aboba
- Re: [Webtransport] Confirming consensus calls fro… Martin Thomson
- Re: [Webtransport] Confirming consensus calls fro… Victor Vasiliev
- Re: [Webtransport] Confirming consensus calls fro… Martin Thomson
- Re: [Webtransport] Confirming consensus calls fro… Alan Frindell
- Re: [Webtransport] Confirming consensus calls fro… Ian Swett
- Re: [Webtransport] Confirming consensus calls fro… David Schinazi
- Re: [Webtransport] Confirming consensus calls fro… Ian Swett
- Re: [Webtransport] Confirming consensus calls fro… David Schinazi
- Re: [Webtransport] Confirming consensus calls fro… Ian Swett
- Re: [Webtransport] Confirming consensus calls fro… Eric Kinnear
- Re: [Webtransport] Confirming consensus calls fro… Martin Thomson
- Re: [Webtransport] Confirming consensus calls fro… Alan Frindell
- Re: [Webtransport] Confirming consensus calls fro… Ian Swett
- Re: [Webtransport] Confirming consensus calls fro… David Schinazi