From nobody Thu Feb 9 08:37:42 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 E9FE2C151522 for ; Thu, 9 Feb 2023 08:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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] 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 vzXEQpyGLA6T for ; Thu, 9 Feb 2023 08:37:41 -0800 (PST) Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) (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 385AAC169522 for ; Thu, 9 Feb 2023 08:36:06 -0800 (PST) Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-16aca2628c6so1018994fac.7 for ; Thu, 09 Feb 2023 08:36:06 -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=fBOJBYllLDhxW99VKAgZM+gYjPIa6AeBsfvRTAArkLM=; b=CXJc+mDnZCfqcGypoA/dHRV/TQwHIaL9GU/vn+AgkCFMSj3qrNNfVLgG1nwlUGw9/d R754n9QiU8m6UqLhp3Cu9ojwKkHVN2srm2YTBZ7304s9+IY/SyHQdbtv4hIjxU8z/div iaPSQBHNZ8t+J65DQ89VAGlDnnVZVlGJdbpprb2B32EyIJH3kMMBY7wirzou0vnIqQ1Y tE01Mr6GOFUovQaFB7dUeaj7MicorGcOIOf7+HdjakebIxbwbAGXcBMwTkkxrs5Jy2RK ExJ4wjIjwiDtq4AR5hiT4IWgBtHogJbQINP7Q7oSgUhZlHJG/lUPJI1dX+rk6KYW+Ny8 gr1g== 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=fBOJBYllLDhxW99VKAgZM+gYjPIa6AeBsfvRTAArkLM=; b=VQEzxlnF7U6WWlaIsgbygPWsu5VN6OG8LucOer/2K6Sz9fbPwTJ7eRAc89TDWniDdb qs4s9ufyf+moOM/FF5OokD0GsXx8UZRXbjJlyXSEMMqLNR6IhkPXS+q3ICWaiV0aeo0c jpFaJ5z1SbigQ5gxSkLN8BesacXNZdqnqNKTKgf4Ffuiz7jrbmqXeAn4IDnuAFErDXOD o103zRqRltTROSUfTod3sjNnYLDbTA2GEVBlSYwdsWdNA3O8SsEYD1S2fKAkVXJ+yUlV TtKJtXUUwUB9/DmfIrA+NMBYkaOz7FVDAS1CFs1Im0TyeDeQRmqwMn+KQbOqWOdtCyHK 21jw== X-Gm-Message-State: AO0yUKUBJ2nfqzhrIER9mB3AmJNcjsxaFrjk+FfUBU3OV+vu+jZfQpRi gVnKhcv+xFL3bBVMxsvlcQ0FvwNn+hARTf+ifW1Vdy8J X-Google-Smtp-Source: AK7set+/YvSgVz4qEn9WUfyEouHRqW5tKwBwOIKIUsiqu21ajgLnrqm5I4MZQ31kVaWn0082cApi/XI41B+gkLH8Urs= X-Received: by 2002:a05:6870:c153:b0:16a:2cff:e2b2 with SMTP id g19-20020a056870c15300b0016a2cffe2b2mr1070661oad.4.1675960564559; Thu, 09 Feb 2023 08:36:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Thu, 9 Feb 2023 16:35:49 +0000 Message-ID: To: Spencer Dawkins at IETF Cc: Luke Curley , MOQ Mailing List Content-Type: multipart/alternative; boundary="0000000000001bb53605f446fa32" Archived-At: Subject: Re: [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: Thu, 09 Feb 2023 16:37:42 -0000 --0000000000001bb53605f446fa32 Content-Type: text/plain; charset="UTF-8" Hey Spencer, On Thu, 9 Feb 2023, 16:00 Spencer Dawkins at IETF, < spencerdawkins.ietf@gmail.com> wrote: > Lucas, > > On Wed, Feb 8, 2023 at 4:55 PM Lucas Pardue > wrote: > >> >>> And yeah, I agree that browsers are the main obstacles when pushing >>> media, but that doesn't change too much with WebTransport. We still need a >>> way to set the priority when pushing a WebTransport stream, much like we >>> would need a way to set the priority when issuing a HTTP PUT. I suppose >>> it's easier to modify WebTransport since it's in development. >>> >> >> The W3C WebTransport WG has been considering the questions of >> prioritization and congestion control feedback for a relatively long time. >> And we have been making progress. It has the right people and the right >> charter to work on it. I'm a little pessimistic about trying to get >> momentum for HTTP upload changes MoQ could require, in the sorts of >> timeframes that MoQ would find useful. For context, fetch *does *even >> support preference of HTTP version, nor exposese connection pooling. But >> maybe I'm too conservative in this regard. Asking ourselves the questions >> is definitely worthwhile. >> > > Could this have been "fetch *does NOT* even support preference of HTTP > version"? > > I was guessing so, but didn't want to guess when I could ask. > Yes you're right. Thanks for spotting that! I always appreciate a careful eye. At the HTTP semantic layer, the version doesn't really matter, your request or response objects get transferred around. The same scheme value "https" works for all versions. Under the hood there's lots of differences and complexity of course. The Fetch API feels about the right layer of abstraction for most purposes. My sense so far has been that QUIC is providing unique qualities that the MoQ protocol (whatever it is) wants to harness. If that's true, HTTP/3 is a hard requirement of an HTTP-based MoQ protocol, then we'd have work to do in the web platform to ensure its abstractions don't get in the way. Likewise, implementation details like internal stacks, layering, security model etc would need to be considered. This isn't an impossible task but nor will it just happen without investment and engagement. Cheers Lucas --0000000000001bb53605f446fa32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Spencer,

On Thu, 9 Feb 2023, 16:00 Spencer Dawkins = at IETF, <spencerdawkin= s.ietf@gmail.com> wrote:
Lucas,=C2=A0

On Wed, Feb 8, 2023 at 4:55 PM L= ucas Pardue <lucaspardue.24.7@gmail.com> wrote:
=

And yeah, I agree that=C2= =A0browsers are the main obstacles when pushing media, but that doesn't= change too much with WebTransport. We still need a way to set the priority= when pushing a WebTransport stream, much like we would need a way to set t= he priority when issuing a HTTP PUT. I suppose it's easier to modify We= bTransport since it's in development.

The W3C WebTransport WG ha= s been considering the questions of prioritization and congestion control f= eedback for a relatively long time. And we have been making progress. It ha= s the right people and the right charter to work on it. I'm a little pe= ssimistic about trying to get momentum for HTTP upload changes MoQ could re= quire, in the sorts of timeframes that MoQ would find useful. For context, = fetch does even support preference of HTTP version, nor exposese con= nection pooling. But maybe I'm too conservative in this regard. Asking = ourselves the questions is definitely worthwhile.=C2=A0

Could this have been "fetch does NOT e= ven support preference of HTTP version"?=C2=A0

I was guessing so, but didn't want to guess when I could ask.=C2=A0

Yes you're right. Thanks for spotting that! I always apprec= iate a careful eye.

At t= he HTTP semantic layer, the version doesn't really matter, your request= or response objects get transferred around. The same scheme value "ht= tps" works for all versions. Under the hood there's lots of differ= ences and complexity of course. The Fetch API feels about the right layer o= f abstraction for most purposes.

My sense so far has been that QUIC=C2=A0 is providing unique qual= ities that the MoQ protocol (whatever it is) wants to harness. If that'= s true, HTTP/3 is a hard requirement of an HTTP-based MoQ protocol, then we= 'd have work to do in the web platform to ensure its abstractions don&#= 39;t get in the way. Likewise, implementation details like internal stacks,= layering, security model etc would need to be considered. This isn't a= n impossible task but nor will it just happen without investment and engage= ment.

Cheers
Lucas
--0000000000001bb53605f446fa32--