IETF Logo Mail Archive

Re: [Webtransport] Use of HTTP priorities in WebTransport

Luke Curley <kixelated@gmail.com> Mon, 05 April 2021 19:47 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 E52173A2534 for <webtransport@ietfa.amsl.com>; Mon, 5 Apr 2021 12:47:44 -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=unavailable 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 GnSp-OG69Ezp for <webtransport@ietfa.amsl.com>; Mon, 5 Apr 2021 12:47:40 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 A7AB73A2532 for <webtransport@ietf.org>; Mon, 5 Apr 2021 12:47:40 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id w203-20020a1c49d40000b029010c706d0642so95351wma.0 for <webtransport@ietf.org>; Mon, 05 Apr 2021 12:47:40 -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=pQhOvcGUpTIsF7E795RBxvlpV89Wl/Al109dXezT5vg=; b=HLsSdkn5VZ4YJ9+ilXq15D6E1AR0c4hm4gsqlvZB9YqGMvJF9RRCaYgYBhT82vEDfQ Jpgd/cWbhgSNqoU8y+2Iup/Xy1lL7HNY14heJjwEeISaAf1J/JCLe08jqx/J/bEVK/Zw slzS9mgqUdAA9383W/0w82lR4KjofDQGDag8vcWzJ9UF/ncPO9du2h+Cl/3X6eb2MpeL Qw0AZ59YgRk+PShN/B9bXaO3B0VHcirumVxtX+m916UjxZlrkUTHp+jQYu0cq11vCVzO BLJHBbqireqlsEhlMq6+cPzJUVqVs4n3992NJsEsY4Yj5c6+1J87aeinDAP419yIn8rR L3Vg==
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=pQhOvcGUpTIsF7E795RBxvlpV89Wl/Al109dXezT5vg=; b=jqOaMJk4AgrNn4BRohF1mGyO+8/hy8yDL2cnAntEIm9JoXof8ZI3yTbpKwLre2wzii OtfDwIVBx9X8/lpSFuqG2cgHk+ynl+KD02j7Cp7tsS8AQ3vDSqsw4mgVhO8QBYcePtWY 3oc27mwp3JrweRN15+f3jrJj0yorcjoSM6OGzX6uZSsYEHnBmWEcwiruDGASoPbfDkyz IZzYLIlHBNx5L1puFRZG6lj7bW3mlMXFcq1CSVdTv3x3srxhVdCC/T7XRGYFJ3FuBdrZ mMLpDR8yKZ/47+h03X3gur1Y3ueXkgVPWUG4nWSpfakJVUEwNJ22GFovszFTWVJKkoe+ VX6w==
X-Gm-Message-State: AOAM533OSVrEG4hbuR4+k7it2jIEfkUQTh3mmIeIOB79+VA/RD+Nnq5a BKM88FtwMAwCDHd34B7lg8k28ehsmDpIwx5xh9c=
X-Google-Smtp-Source: ABdhPJwlDGURNqCAJNGkbU7jy1yak8FmPZ4un5pD+2q5WfynwlNwWJt5DnpouYFEy9E0EjKYIYiVqqvS95UwhOAhm0E=
X-Received: by 2002:a1c:b002:: with SMTP id z2mr599010wme.121.1617652057527; Mon, 05 Apr 2021 12:47:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAKcm_gOMcFYF2YROhsbVW15Q+tnWfwGsHhrjxQwq1jJAyvLvVQ@mail.gmail.com> <CALGR9obOXRk=ZxL8Sj9zhsP-wQyv_09doZuzfCSRzquw4CZFYw@mail.gmail.com>
In-Reply-To: <CALGR9obOXRk=ZxL8Sj9zhsP-wQyv_09doZuzfCSRzquw4CZFYw@mail.gmail.com>
From: Luke Curley <kixelated@gmail.com>
Date: Mon, 05 Apr 2021 12:47:26 -0700
Message-ID: <CAHVo=Zmo0Nta92_Ub0m8v6+=hjQ1iR6R9Aa==fe_-VXkhJEJYQ@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, WebTransport <webtransport@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000425a2805bf3ef88b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/45iOgG3Gkt0XH5wCsmp9dwFOiI8>
Subject: Re: [Webtransport] Use of HTTP priorities in WebTransport
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: Mon, 05 Apr 2021 19:47:45 -0000

I think stream prioritization is an important next phase for WebTransport.
But like Lucas mentioned, I'm not sure it needs to be handled at the
transport layer.

Currently, the server can prioritize sending stream data based on any
scheme it wants. The browser could inform the server which prioritization
scheme to use for a given stream, but I think that use-case can be
negotiated at the application level instead.

The browser definitely needs an API for prioritizing sending stream data
though and a simple scheme like the priorities draft would be a good
starting point.

On Thu, Apr 1, 2021 at 4:40 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Hey Ian,
>
>
> On Thu, Apr 1, 2021 at 6:01 PM Ian Swett <ianswett=
> 40google.com@dmarc.ietf.org> wrote:
>
>> Now that WebTransport is targeted at HTTP/3 and not QUIC, it seems
>> logical to build on the prioritization work in the HTTP priorities draft(
>> draft-ietf-httpbis-priority
>> <https://tools.ietf.org/html/draft-ietf-httpbis-priority-03>).  This
>> could be particularly important when pooling HTTP/3 with WebTransport, but
>> I think that priority model is a good one for WebTransport by itself as
>> well.
>>
>> Except for bidi streams, most of this priority information wouldn't need
>> to be sent on the wire, but it could be used by local schedulers.
>>
>> Thoughts?
>>
>
> The HTTP priorities draft is very specific in that it defines an
> asymmetric signal from client to server. So I'm curious how you picture it
> applying to WebTransport. You're right, the general prioritization scheme
> might be a good fit but I'd like to understand the requirements better. Is
> it only a local priority configuration from the send side? In which case,
> this seems like a W3C API issue. Or is the requirement to support sending
> priority signals that instruct the peer to do something too? The hardest
> case to solve is a server-initiated bidi stream that wants to signal a
> priority to the client. Since WebTransport over HTTP/3 is an extension, you
> might get away with changing the rules for PRIORITY_UPDATE. You could
> define a new frame that carries the same information, or include it in the
> WebTransport stream itself somehow.
>
> Cheers,
> Lucas
> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>

v2.23.0 | Report a Bug | By Email