IETF Logo Mail Archive

Re: [Webtransport] HTTP/3 Downgrade

Bernard Aboba <bernard.aboba@gmail.com> Wed, 11 November 2020 22:35 UTC

Return-Path: <bernard.aboba@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 8CC3C3A11A2 for <webtransport@ietfa.amsl.com>; Wed, 11 Nov 2020 14:35:41 -0800 (PST)
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, DC_PNG_UNO_LARGO=0.001, 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, 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 vf7h-VV4e_es for <webtransport@ietfa.amsl.com>; Wed, 11 Nov 2020 14:35:39 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 C47023A119B for <webtransport@ietf.org>; Wed, 11 Nov 2020 14:35:38 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id z21so5421638lfe.12 for <webtransport@ietf.org>; Wed, 11 Nov 2020 14:35:38 -0800 (PST)
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=MrTB0ob3dM6sCR+R3SK2Vl13jkhGtGU2bIt3zsXW6qo=; b=Temp+CDkbdR/3G57RRh23s/ZPdC6z5wv16AP02KskUvu96evvFiI54mC4FXR6hV6ZK 4y9/2+VrbNhIjKthZykGK6hUY8Ho+MtAKAJ885E6nOYpW9AtO8jMgKjL5Fl2n/9Z0RPm r+Z/BCFlOcYcPZdNQO0WykJhJLqpN9KvcrY9hDOlMlu3D9+KYZL7rGm5p3o9q8j+Ls/e N5xRxzTF5vA4wGUsJYcduonKnub2M0+XZKz4hLgNuAiFpjYcqIZJZyKh396epKWGzwPn Z1FcKMZw34ZsqpGXvvsOaJK7KALvi5zLb3ihBPEwIy5H+3oGDM55PItDL3t8OaygXztZ DFFQ==
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=MrTB0ob3dM6sCR+R3SK2Vl13jkhGtGU2bIt3zsXW6qo=; b=MvlqTysEKK0Th7S2qzbX5plr7xEuWZrf89OG+wcP2qxcn+S/Q65ehThyt9ScHwKw0F KaUPG9yCZWNEgdBN3SiKUGticzAmb/ER2WICVV9/AMnpX6nAB2YddsXFmwYP9MLSuMAw PlKINeiD7l+g5orL+XpQpc+obezK5geit0a1eqAFh7eInB28xcpxjJXEIb8W2xLXrVeo 5RKIMqvzj4MzSxVXA+4GbtiElO8p0la96E4pAWDQugoPto6jlnwJ43BcObxF+k2eq8Xp 9u/8HoTseIBJIObdnwAOiqNsaiG78tj6cfaNM3voAYdGqmO6iSzGQkLsrBcHwlQq+Q2o ueWg==
X-Gm-Message-State: AOAM5325xKkwlD6pgvPvPgYJuBIcJYv1fn2esyS/8nB/ZGsF6Ida2fAo 28TzaaWjUnjvuDDzAdZi4Vo2AxQ+ZgXuZSbx+/I=
X-Google-Smtp-Source: ABdhPJwReEzJhEvuQMHrwGQlReZjAYIJ2KDHpRpVcUyOxMGIOLRuKqyKuTlRW/atkJEkMvOYMQnAMbEUXVn24O2XTuk=
X-Received: by 2002:a19:88c:: with SMTP id 134mr9716822lfi.560.1605134136375; Wed, 11 Nov 2020 14:35:36 -0800 (PST)
MIME-Version: 1.0
References: <CAHVo=Zk84mfOJr3XSXmrVDBq0XUKoB63ytCR1dhhtM7aehq7qw@mail.gmail.com> <CAAZdMafmO3qKQKegJ7X+MvTjnPvKnO3+B1T-aRME6FZqL-e_1A@mail.gmail.com>
In-Reply-To: <CAAZdMafmO3qKQKegJ7X+MvTjnPvKnO3+B1T-aRME6FZqL-e_1A@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Wed, 11 Nov 2020 14:35:25 -0800
Message-ID: <CAOW+2dv8bGfftqZYFnPGpOX+XPzydh4_KJjknhu5FxP-w1neTw@mail.gmail.com>
To: Victor Vasiliev <vasilvv=40google.com@dmarc.ietf.org>
Cc: Luke Curley <kixelated@gmail.com>, WebTransport <webtransport@ietf.org>
Content-Type: multipart/related; boundary="00000000000004417f05b3dc6ae3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/Hvj9S8c95uuWaYrFbUUsfJjEEOw>
Subject: Re: [Webtransport] HTTP/3 Downgrade
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: Wed, 11 Nov 2020 22:35:42 -0000

Victor said:

"Http3Transport without pooling doesn't make that much sense."

[BA] Some Http3Transport use cases depend on pooling between WebTransport
and HTTP/3 request/responses; others could just be satisfied by
WebTransport pooling.  I would suggest that we distinguish these two
requirements, because pooling/sharing a QUIC connection between
WebTransport instances appears simpler than pooling/sharing a QUIC
connection between WebTransport and HTTP/3.

At IETF 107 RIPT BOF there was a desire expressed to enable media services
to leverage HTTP infrastructure. Justin Uberti described a use case where
gRPC would be sent over HTTP/3 to request that the server initiate either a
reliable stream or flow of datagrams (see below).  This use case appears to
require pooling of WebTransport and HTTP/3 request/responses (in order to
simplify firewall traversal).  However, this use case is not easily
supported using an garden variety HTTP/3 server, which probably could not
initially be expected to support QUIC datagrams (although it would not be
hard to support in node.js assuming that a QUIC module was available).

See Slide 7 here:
https://datatracker.ietf.org/meeting/107/materials/slides-107-ript-rtc-implementation-experiences-00

[image: image.png]

On Wed, Nov 11, 2020 at 1:52 PM Victor Vasiliev <vasilvv=
40google.com@dmarc.ietf.org> wrote:

> I'm not sure "HTTP/3 without pooling" does anything that QuicTransport
> doesn't already do, especially since the latter got real header support.
> So, at least as far as my understanding of this space goes, Http3Transport
> without pooling doesn't make that much sense.
>
> On Wed, Nov 11, 2020 at 4:43 PM Luke Curley <kixelated@gmail.com> wrote:
>
>> It seems like connection pooling introduces a lot of technical complexity
>> for limited benefits. Hypothetically, what if connection pooling was
>> dropped as a requirement?
>>
>> What if Http3Transport involved establishing a new HTTP/3 connection and
>> downgrading it to QUIC? It would be analogous to WebSockets for HTTP/1.1.
>>
>> You could use 0-RTT to minimize latency when establishing a HTTP/3 or
>> Http3Transport connection to an existing host. These connections would not
>> share congestion control state (unfortunate), but would also not share flow
>> control limits (yay).
>>
>> I also think this is how you could merge QuicTransport and
>> Http3Transport. Use HTTP/3 for the handshake, and QUIC for the data
>> transfer.
>> --
>> 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
>

v2.23.0 | Report a Bug | By Email