IETF Logo Mail Archive

Re: [Moq] Proposal for "QUIC on Streams"

Ted Hardie <ted.ietf@gmail.com> Mon, 26 February 2024 18:10 UTC

Return-Path: <ted.ietf@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 297D2C15171B for <moq@ietfa.amsl.com>; Mon, 26 Feb 2024 10:10:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 Cza0dyZwCfhX for <moq@ietfa.amsl.com>; Mon, 26 Feb 2024 10:10:31 -0800 (PST)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 80F19C151981 for <moq@ietf.org>; Mon, 26 Feb 2024 10:10:26 -0800 (PST)
Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-dcc4de7d901so2626863276.0 for <moq@ietf.org>; Mon, 26 Feb 2024 10:10:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708971025; x=1709575825; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Md/MMVNsNcH/W97SRB7d8llVEy5j29Ug7afqHgsJTUo=; b=Oar1uD7dqfY5PYRJjYtUeBXsDtF4BTNAz29kmghj0wCuT2jKVDsGDubIqpIr1aURCE ZZcSg/B/Tskd8vFv7b/NdLjs7wrxVznbUa95Lvx69yY38wi5/YqXTPAvg84e1g7++sF/ O/Exy6NYsrk1XXhZnxjdO5rZZkx/VPj89VvXy8ooOdYyjjiicmyoCs1QoFZkMsNUT3LR PFLGnaZgOJHwfuvaz6nsYfMwFV5i7xp5djgZWVPE+7y1Th+n4hAQ8Fc4a3B0WLmE6g7Y z2ETsKoR5jnGK5wDKcOqHs2h0IO4EO/DSF/PHRLivfCA5uUK9Piwq9Uh5Eb4rMfuMUzN SvmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708971025; x=1709575825; 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=Md/MMVNsNcH/W97SRB7d8llVEy5j29Ug7afqHgsJTUo=; b=n8dkth4UiVngiUiZAp90JaDiodW8STD1ccQMxjYFehhPlMOpCQ1QbusXuBA3vu+CvS 9X6hT6ANoZDt3yxHDgZ8hMBz8ks4fsoRG22SJSxOSdBNakI12DL3jLQSgsq44kIIccZU 9m82O/72wmoo6UD/zSfwFP1L1uF4zIWE+/hk9wbwc6uVjMk7CpiulqjXdo2nxRizMKA2 Wu9Uxx+oIoGQqkxJ5/IM6ufm/Yioooz9I+F6XTXrsGZNc189u9PjBGQcDfAMBWMdZzYI zbkY0iz/KCxgroYus+414sIWIM7mRV/L+lQIXZ+pY9d0Wni0qJ6vINlDmUF+u903Kh8v JRXA==
X-Forwarded-Encrypted: i=1; AJvYcCWXFpN06XgDPJRYuM1UAOrB7WG8PHifvmvjMhYLLghSEkn+rnUp2Eax4WAybx+45/gnOQk8hpNAilMpUAw=
X-Gm-Message-State: AOJu0YwbexzJLWaWY+OjdXv/iDQJGbC/j0HPRrU54EabFX/tjA5wIsVM X7r35nsSe4m5+6MWCXgaYyHtfVNRuC/zbhy1X41xhmOkxtCzjG7gxgV6sxp98tiZG/BCdNUJ0KH 4gMSSlrsi+I4l+PhLADkUJrKXsak=
X-Google-Smtp-Source: AGHT+IF2b5ITDGLd5gL6dOQAQ42odteXNh9ji3Sn5j+yYuoT8NbbUsehTkGR3Cls2EvWvovKMw8kHf4KhXxBiomSZI0=
X-Received: by 2002:a25:918a:0:b0:dcd:1d44:f6c1 with SMTP id w10-20020a25918a000000b00dcd1d44f6c1mr4708929ybl.16.1708971025332; Mon, 26 Feb 2024 10:10:25 -0800 (PST)
MIME-Version: 1.0
References: <CA+9kkMC1VbFX-ub4GT+6eMvR0VT=Bmd-05Nt0Z=wbiLKJ_Xu9w@mail.gmail.com> <E7AE0A81-2CFF-410F-855A-D9C02BE0C2F6@iii.ca> <1d76ca46-6d69-46e6-acd6-b38116033fa3@app.fastmail.com>
In-Reply-To: <1d76ca46-6d69-46e6-acd6-b38116033fa3@app.fastmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 26 Feb 2024 18:09:58 +0000
Message-ID: <CA+9kkMDzrDRp1GQAPPbtzs+9xeKkid=Ckfg9x=60R5fVqjHAvQ@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Cullen Jennings <fluffy@iii.ca>, MOQ Mailing List <moq@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e57fa806124cd291"
Archived-At: <https://mailarchive.ietf.org/arch/msg/moq/HZ87IM0ipT4Ez0Nsc9l879iYw74>
Subject: Re: [Moq] Proposal for "QUIC on Streams"
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: Mon, 26 Feb 2024 18:10:35 -0000

On Mon, Feb 26, 2024 at 5:33 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

>
> However, that problem only really exists where there is a bandwidth
> bottleneck and/or a lossy path.
>

To pile onto this, the eventual question will be the extent to which the
bandwidth bottleneck or lossy path overlaps the UDP blocking path. i don't
have any recent data on that, but I think it will inform the set of design
choices when we get there.

regards,

Ted



> I can imagine scenarios where a closed circuit has a higher quality path
> and therefore doesn't need these features so much. There, QUIC on Streams
> offers potential for performance advantage, rather than to be viewed as a
> fallback, because you defer packetization, loss recovery and congestion
> control to something else. For instance, if there's a publisher and relay
> on the same box, a simple pipe would be enough to allow QUIC frames to be
> exchanged.
>
> Cheers
> Lucas
>
> [1] - https://lwn.net/Articles/560082/
>
>
>
> On Feb 16, 2024, at 2:40 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Lucas and Kazuho have proposed a mechanism to bring QUIC to any transport
> that provides the stream mechanics that it needs; see the proposal here:
> https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams
> and the discussion ongoing on the QUIC list.  To simplify a great deal,
> this runs QUIC on TLS over TCP when UDP is not available.
>
> It would be interesting for folks building MoQ systems to consider whether
> this would provide adequate fallback for MoQ when QUIC's current stack is
> blocked by UDP failures.
>
> There is a companion draft on running HTTP/3 over QUIC on Streams,
> https://www.ietf.org/archive/id/draft-kazuho-httpbis-http3-on-streams-00.txt
> (see also draft-ietf-webtrans-http2).  I don't think this would be required
> to implement MoQ, but its requirements will probably largely drive the
> discussion on QUIC on streams.
>
> regards,
>
> Ted
> --
> Moq mailing list
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq
>
>
> --
> Moq mailing list
> Moq@ietf.org
> https://www.ietf.org/mailman/listinfo/moq
>

v2.23.0 | Report a Bug | By Email