IETF Logo Mail Archive

Re: [Moq] Exploring HTTP/3

Charles 'Buck' Krasic <charles.krasic@gmail.com> Thu, 09 February 2023 19:28 UTC

Return-Path: <charles.krasic@gmail.com>
X-Original-To: moq@ietfa.amsl.com
Delivered-To: moq@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C96EC15257C for <moq@ietfa.amsl.com>; Thu, 9 Feb 2023 11:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H47ULs48qm3q for <moq@ietfa.amsl.com>; Thu, 9 Feb 2023 11:28:15 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A49BC1516E1 for <moq@ietf.org>; Thu, 9 Feb 2023 11:28:15 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id bp15so4562278lfb.13 for <moq@ietf.org>; Thu, 09 Feb 2023 11:28:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SQVpMbn6VS/AyciD/VG7bMXAJMAh6F1h43OEZCdrOVw=; b=eP46XpQYftuiqN+U1YzMeMdTh3t8CyLyGz6Wn2ZtTCezqFaqU3CWRMGGGWdCNXQya5 /mEEu8cSIexid9lhIrCZY5oKSIroi8gZceUV+z+cqiujZlfE59o+Ul1DKa60jhZqvgCH Ao+bkoKfPV8s5JD+/8EsR9Yoi8puYKJEPZ3cXlKmkwO89UvFm6NgQah4hEpFw00U3cew vi7WFTaclznlWBYgKxFlIOs/PSA/WstKjw0ipsP/7JRlacQJr8rJx8CYuRpDYUfNzTAU z78piflG73yZYc/vze3bWEUfXgZ4+RiLyxCVhEEG9Hpv7Qs3qqP24cvH3T3Wbiofatzl dY3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SQVpMbn6VS/AyciD/VG7bMXAJMAh6F1h43OEZCdrOVw=; b=XzSErYrfG0D7g1mo04kQEv5iO+1Wmp+h2d8qlvKWayp5tKhNMSPabrPpYaeQi2MhiB PgNotKc84kb/dR7ko6+aYSfvlV+MuyjPqQhC3ctZwuf+TJbGEeXBQywGPd++ykzhxk9z +YYkfs2cVweFE2zMXaL0YtAtKO/N2VvuUNU0RviIMBXLviqD6bfYUeDG0H1l950113W5 6TC9s0hY3/tX0H/EtuJgaxfCVv32CLmfgCziX6hnwmuZMjVfnWP8xOXmGB0Na92oDu/o PcxPL4HT01AWdHfHu2fHb/TvtcLsExT+h+ym7hGJpEnAn5PPO96ouK2LvHq0dDKAPRDO 00cA==
X-Gm-Message-State: AO0yUKUmutOaQRMTL3FxJzkvfPry1CaAyMpLWeHPXptJO9nvetFGRvsg 8POenl7eCr0EN0+QjPDE9+0OkskYSf0/7qnylbFKcMxFLtE=
X-Google-Smtp-Source: AK7set+XXZavepwq0r48fuIrtx1Ljp5uZcWB4h2LdPgFXixmmwh0hXh/xBTn9VYSqSGt7jMqxcqYhIHmAe2Tu00ALqw=
X-Received: by 2002:ac2:5df3:0:b0:4ca:f9e4:c410 with SMTP id z19-20020ac25df3000000b004caf9e4c410mr1713648lfq.97.1675970892416; Thu, 09 Feb 2023 11:28:12 -0800 (PST)
MIME-Version: 1.0
References: <CAHVo=ZmD7KvKxh2tTeaM2B+0q9=qZPgBydmfaHor5MaPODZf6w@mail.gmail.com> <CALGR9oas8cMBrX1WVf64fH13jr1r-S0KQB5spNzFj41k9Lgk+A@mail.gmail.com> <CAHVo=Z=Nov7B24A=M2pxPnUgyBg3n-AjF8AD2mKwgbTQ81F+mA@mail.gmail.com> <CALGR9ob4i7Z8zuqFVHtzOGV3QMTFjvOK4uZW3Xfvb5ZsoULvMg@mail.gmail.com> <CAKKJt-eC=h20Va4+64r=zkhYXK_ypC+txLqzgpr+YL=HW-DD+g@mail.gmail.com> <CALGR9oYr2OZZcfmFdqLgQ0Uqu7pAwQTnbuf-Fm64m58Spe6xYw@mail.gmail.com> <CAHVo=ZmeJfdoLc9NatDDEeAQG0X9_aygQm0ZSdtzeKEu=bO2pw@mail.gmail.com> <CAOW+2dsgewEtqnT0i=drp5dRDvDtMyKyojEn0sp7Htx6SOJ3Uw@mail.gmail.com>
In-Reply-To: <CAOW+2dsgewEtqnT0i=drp5dRDvDtMyKyojEn0sp7Htx6SOJ3Uw@mail.gmail.com>
From: Charles 'Buck' Krasic <charles.krasic@gmail.com>
Date: Thu, 09 Feb 2023 11:28:00 -0800
Message-ID: <CAPhuoz1xrHv+HqmVhE0v-xRKn3fyNKmZq3ckwrDq_rXK=y1Ltw@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: Luke Curley <kixelated@gmail.com>, Lucas Pardue <lucaspardue.24.7@gmail.com>, MOQ Mailing List <moq@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b249f005f449618f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/moq/Fj5cigqplYxF3jMzsqtQAenA7RY>
Subject: Re: [Moq] Exploring HTTP/3
X-BeenThere: moq@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Media over QUIC <moq.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/moq>, <mailto:moq-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/moq/>
List-Post: <mailto:moq@ietf.org>
List-Help: <mailto:moq-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/moq>, <mailto:moq-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2023 19:28:17 -0000

On Thu, Feb 9, 2023 at 10:18 AM Bernard Aboba <bernard.aboba@gmail.com>
wrote:

> On Thu, Feb 9, 2023 at 09:56 Luke Curley <kixelated@gmail.com> wrote:
>
>>
> For example, suppose a client issues a request for segment 5 and segment
>> 6, asking that the newer segment is delivered first during congestion.
>>
>> If the two requests share a HTTP/3 or HTTP/2 connection, then the HTTP
>> server can prioritize. Any available bandwidth under the congestion window
>> is spent on STREAM frames for segment 6 first.
>>
>
> [BA] Couldn’t this be accomplished without priority, by having the
> receiver send a STOP_SENDING frame for segment 5, once it became clear it
> was taking too long?
>


By the time the STOP_SENDING arrives at the server, priority-inversion
damage may have already occurred.

At a minimum, this is influenced by one-way delay.   There can be other
delays.  For example, if it is using fetch, the receiver may have somewhat
limited visibility into progress as bytes arrive, it may be subject to
execution jitter if there is competion for CPU, etc.  so in addition to the
one-way-delay required for STOP_SENDING to reach the server, there may be
material delays for the receiver to reach the decision to cancel the
segment, abort the segment, and the stack to actually emit STOP_SENDING on
the wire.


> --
> Moq mailing list
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq
>

v2.41.0 | Report a Bug | By Email | System Status