From nobody Wed Feb 8 10:33:30 2023 Return-Path: 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 4B8A2C1524DE for ; Wed, 8 Feb 2023 10:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 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_NONE=-0.0001, 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 gM1OJmAI5V-n for ; Wed, 8 Feb 2023 10:33:28 -0800 (PST) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 9987AC14F74B for ; Wed, 8 Feb 2023 10:33:28 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id lu11so53403176ejb.3 for ; Wed, 08 Feb 2023 10:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=m45q5ePJouZYyBd7Jnx37uD67DHByShSjok6z6tH1lw=; b=JK87LvU9Ur93TmxyKHvzbVyj+FUvzxp2qeut0x0Cxf2fKdE5IaCnk3HgdGRMkyiyZy 6bcPJJo+vyLYoPmyCFZQuM7l8UskSJFwKN3M1yn5LLL0i7PROlOrzFbMeUy4savckP5V etjHIgWKbTcBYEyIpNZeaLhfq6sJ/zqegt2oYBFuEAb3ZlJJioaUqu3GVni6mn7/Fazq p+kMU7KtqE9bzyMhRpV5gNFLV+c7COB87hjd2MwNyScEq4KCubwjc+g+ue0kHKA7hYad CsVVyqqVzWqxQse1YDv0/fyMjU5DQVnFnGd8EDMLXYidV3yGHV7tqZ/cw0K7zYaLX5Uu wXsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=m45q5ePJouZYyBd7Jnx37uD67DHByShSjok6z6tH1lw=; b=iMif5CoZclC4oMSool59rOmCVfKvvo6cKmMFSpszrhi4XgE5EG3xlrk+DHhHCPRyD9 Bs4cFAB3sk9NMdLFbidLVX6g0sFICrOXulNM6cncnSACELzc4Kh0AkxFNi0ZmADzMli8 WmgrO6Hb2SsktUfz8uQ6Akb3+mKL7pP4XrjtK+HCLETslsRmRcWfo0T/i9P1j2o00OZN hEWJIZzMtZ5wz2rtZSsXm/WGOWOWsdhR3UNHuPN5/4f25Cg/lkZGlLoIpPAeDfc0wDtl CERhyD28WSAAcTEIVdXYh4ILB8/7QE2jE9O5HWaRNaMSgG3JXLnrfr3xRVu+yM+YjUAz 3Fpw== X-Gm-Message-State: AO0yUKXdIBz1GnHmm7CLPiN391yMGGgtVTmlkejWIaUHcvmGDKXvCbXw 3LWgYZsbLDXO736mQMd5mxbRx8DfN0DrTAgqNksmbse6xI156w== X-Google-Smtp-Source: AK7set+ptmFnuOstuw9FIUfa5F8/V6mxS3Dzhyf5Cdwe0+518nnbzbotJT2dQfeRxqd6m0GOvnDiMqDhP+oDcxEHq0o= X-Received: by 2002:a17:906:4d58:b0:87b:d491:4311 with SMTP id b24-20020a1709064d5800b0087bd4914311mr1838300ejv.275.1675881206532; Wed, 08 Feb 2023 10:33:26 -0800 (PST) MIME-Version: 1.0 From: Luke Curley Date: Wed, 8 Feb 2023 10:33:15 -0800 Message-ID: To: MOQ Mailing List Content-Type: multipart/alternative; boundary="000000000000004f7405f43480a9" Archived-At: Subject: [Moq] Exploring HTTP/3 X-BeenThere: moq@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Media over QUIC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2023 18:33:29 -0000 --000000000000004f7405f43480a9 Content-Type: text/plain; charset="UTF-8" Hey MoQ, As I mentioned in a recent email: > The best part about HLS/DASH is the HTTP ecosystem. That includes CDN support, optimized software, and general interoperability. We lose a lot of this by creating a custom pub/sub mechanism. > The worst part about HLS/DASH is the latency. This is caused by head-of-line blocking (buffering) and the client being in charge (requesting playlists and segments). The Warp draft tackles these problems with QUIC prioritization (delivery order) and WebTransport push respectively. I think it's possible to address the problems with HLS/DASH without forgoing HTTP.; WebTransport push is not the only option. At one point I drafted Warp over HTTP/3, but abandoned it because it's more complicated and Twitch doesn't need 3rd party CDN support. Warp's OBJECT frames are strikingly similar to HTTP/3's HEADER+DATA frames, and unironically we're considering using qpack to compress the OBJECT headers. I propose each Warp object would be a HTTP resource instead. This parallels discussion at the interim suggesting we need a way to GET old media for DVR. Head-of-line blocking can be avoided using QUIC (or HTTP/2) prioritization with the Priority header. The client would request each source with a priority based on the contents. For example, request the newest audio segment with urgency=7 while the older video with urgency=4. There's some warts especially involving relays but it's not unsolvable. The latency caused by requests can be avoided by long polling. The purpose of WebTransport push is to avoid the round trip between when the client is informed about new media until it requests it. Twitch uses long-polling with HLS today to accomplish the same thing, preflighting the next request based on a deterministic URL. Prioritization lets you preflight multiple concurrent requests without the risk of them fighting for bandwidth. Alternatively, some variation of HTTP push could avoid request latency. I've said this before, but QUICR looks a lot like a hypothetical HTTP subscription since it's based soley on the URL. Nobody likes HTTP push, let alone extending it, but technically we're building something similar. I would not recommend this direction. I'm mostly worried about how browsers/servers will handle a request per frame. I still strongly recommend breaking media into layers anyway; I'm still not convinced that networks need the ability to drop individual frames. For example, non-reference frames could be bundled together into same HTTP resource, and prioritized lower than reference frames. But in theory that's all we need. I can write up a draft if the WG thinks it would be fruitful to explore this direction. It could be a DASH extension, although it's still important to address the contribution side of the coin (ex. push using HTTP PUT). --000000000000004f7405f43480a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey MoQ,

As I mentioned in a recent= email:

> The best part about HLS/DASH is the H= TTP ecosystem. That includes CDN support, optimized software, and general i= nteroperability. We lose a lot of this by creating a custom pub/sub mechani= sm.

> The worst part = about HLS/DASH is the latency. This is caused by head-of-line blocking (buf= fering) and the client being in charge (requesting playlists and segments).= The Warp draft tackles these problems with QUIC prioritization=C2=A0(deliv= ery order) and WebTransport push respectively.

<= /div>

I think it's possible to address = the problems with HLS/DASH without forgoing HTTP.; WebTransport push is not= the only option. At one point I drafted Warp over HTTP/3, but abandoned it= because it's more complicated and Twitch doesn't need 3rd party CD= N support.

Warp's OBJECT frames are strikingly= =C2=A0similar to HTTP/3's HEADER+DATA frames, and unironically we'r= e considering using qpack to compress the OBJECT headers. I propose each Wa= rp object would be a HTTP resource instead. This parallels discussion at th= e interim suggesting we need a way to GET old media for DVR.
=
Head-of-line blocking can be avoided using QUIC (or HTTP/2) = prioritization with the Priority header. The client would request each source with a pri= ority based on the contents. For example, request the newest audio segment = with urgency=3D7 while the older video with urgency=3D4. There's some w= arts especially involving relays but it's not unsolvable.
The latency caused by requests can be avoided by long polling. = The purpose of WebTransport push is to avoid the round trip between when th= e client is informed about new media until it requests it. Twitch uses long= -polling with HLS today to accomplish the same thing, preflighting the next= request based on a deterministic URL. Prioritization lets you preflight mu= ltiple concurrent requests without the risk of them fighting for bandwidth.=

Alternatively, some variation of HTTP push could = avoid request latency. I've said this before, but QUICR looks a lot lik= e a hypothetical HTTP subscription since it's based soley on the URL. N= obody likes HTTP push, let alone extending it, but technically we're bu= ilding something similar. I would not recommend this direction.
<= br>
I'm mostly worried about how browsers/servers will handle= a request per frame. I still strongly recommend breaking media into layers= anyway; I'm still not convinced that networks need the ability to drop= individual frames. For example, non-reference frames could be bundled toge= ther into same HTTP resource, and prioritized lower than reference frames.<= /div>


But in theory that's all we nee= d. I can write up a draft if the WG thinks it would be fruitful to explore = this direction. It could be a DASH extension, although it's still impor= tant to address the contribution side of the coin (ex. push using HTTP PUT)= .
--000000000000004f7405f43480a9--