Re: [Webtransport] HTTP/3 Downgrade

Luke Curley <kixelated@gmail.com> Thu, 12 November 2020 01:31 UTC

Return-Path: <kixelated@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 28F363A12B5 for <webtransport@ietfa.amsl.com>; Wed, 11 Nov 2020 17:31:51 -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 PbfkXhuAinLP for <webtransport@ietfa.amsl.com>; Wed, 11 Nov 2020 17:31:49 -0800 (PST)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 F056C3A12B8 for <webtransport@ietf.org>; Wed, 11 Nov 2020 17:31:48 -0800 (PST)
Received: by mail-ot1-x32a.google.com with SMTP id 30so4055927otx.9 for <webtransport@ietf.org>; Wed, 11 Nov 2020 17:31:48 -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=t/8evVVE2YCGyuavUcqG2wsYttbAbWXUhngkXMJ9Iyc=; b=dYoHIP1zu11oRqrg7aOf4Aa3T4fZ0DkaT+spn9P504ozhQ7w/M1R5HLWgbHmBxFvqu 9gn6zBs8tq5O/dftsV91SQSIMYC75h/ukVJ7fF/fInvSxiYkeFSZvL2kvWbiuOEb+iLf CLCiZ9oo1koqZ900tiCu/pAp2NQ73iW0/jHJIr9Kzt89RuTQ/ZitUIEJF6n+F8wISCsZ 4AXAgQTGgyQ1u949wZ4ovaqxIQ5moIMWk5xQ1xdPitrwRh2rioXlDOsmfA+zH4KAdFNx eXMeT7Lh9iaE4x9znYRodtlIlm5k7LXVgRZheCohtn+BcikrJDm8URFLSmIVD7VFVJHN qFlA==
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=t/8evVVE2YCGyuavUcqG2wsYttbAbWXUhngkXMJ9Iyc=; b=WpdveRuW3stAgFXxUsGfP8wFph7mv4Wrl5p629a3fxW+a8ZSivE4Sy48VhbYv3bX96 Kqg6Vrro8D0rsoLPN0Z7tXxPvQGPFGSnDfP5+kDl60HzWzYdgqckxhoGkf2lHPq/tAAH TsWGvz0ztn7kN/rF7mOjmLux/WMlnt38AslLbpNooT/IxGTQjRw5q5pyz/UJ07Vrbcet VlxMf1JYU3lzYl/nsH9+7a+4oPFr7Hi45CCp+iR+lR5JGUvHoW+ic+HSu825XpZKdANm aC5aLveFYLM2szuSzhQ7iTU6P/O2La/URRlYHMWh3TzLI9V+yLnUrHeLd4tn6uajRA4K TTPg==
X-Gm-Message-State: AOAM533txc/eDimOgr/QINI5v1UcbpvPsElE/UVDw9ezvzCZ8R9KC4ks P5T6+jvUv7wpCj23eqEi4ZcuKNUwdeDMNTC1sHaI5pMTuYH77w==
X-Google-Smtp-Source: ABdhPJwwxexUR8fcxsuUfwgGQkY8S1gsIoH6/S4HZeZHZPjkySfM0+3wrKIRamk5GE9+ESrq7TOJvYtTgWsoVCYNsBg=
X-Received: by 2002:a05:6830:22da:: with SMTP id q26mr20632248otc.127.1605144707873; Wed, 11 Nov 2020 17:31:47 -0800 (PST)
MIME-Version: 1.0
References: <CAHVo=Zk84mfOJr3XSXmrVDBq0XUKoB63ytCR1dhhtM7aehq7qw@mail.gmail.com> <CAAZdMafmO3qKQKegJ7X+MvTjnPvKnO3+B1T-aRME6FZqL-e_1A@mail.gmail.com> <CAOW+2dv8bGfftqZYFnPGpOX+XPzydh4_KJjknhu5FxP-w1neTw@mail.gmail.com>
In-Reply-To: <CAOW+2dv8bGfftqZYFnPGpOX+XPzydh4_KJjknhu5FxP-w1neTw@mail.gmail.com>
From: Luke Curley <kixelated@gmail.com>
Date: Wed, 11 Nov 2020 17:31:39 -0800
Message-ID: <CAHVo=Zkhav-SqLAPocm2ZtEOwfrjBvOUuJ4egphLiw_UA67JYA@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: Victor Vasiliev <vasilvv=40google.com@dmarc.ietf.org>, WebTransport <webtransport@ietf.org>
Content-Type: multipart/related; boundary="0000000000002093ba05b3dee080"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/RcPFpyAJIKD0L90NIpPrHcgzV5w>
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: Thu, 12 Nov 2020 01:31:51 -0000

@bernard I think that use-case boils down to a lack of HTTP functionality.
The "proper" approach would be to use HTTP server push for media, but
nobody likes that. Justin's ask is to instead to augment HTTP/3 such that
it muxes in QUIC-like connections. I do think it address HTTP's
short-comings, but it's non-trivial and will require custom HTTP/3
implementations.

My use-case is almost identical (Twitch). We're implementing a video
protocol over QuicTransport instead of trying to leverage HTTP/3. It gives
us the ability to push media while utilizing stock QUIC implementations.
All you need on top is a simple API layer, such as JSON messages over
bidirectional streams.

As for firewall traversal, QUIC connections can use the same socket and
would thus share the NAT binding... assuming middleware does not decode
QUIC initial packets. Each connection could end up on different host
depending on load balancing though.

Has somebody formulated a list of pros and cons for Http3Transport as
compared to QuicTransport?

On Wed, Nov 11, 2020 at 2:35 PM Bernard Aboba <bernard.aboba@gmail.com>
wrote:

> 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
>>
>