IETF Logo Mail Archive

Re: Proposal Towards Universal HTTP/3, with a polyfill of QUIC for TCP (Fwd: New Version Notification for draft-kazuho-httpbis-http3-on-streams-00.txt)

Lucas Pardue <lucas@lucaspardue.com> Mon, 26 February 2024 17:54 UTC

Return-Path: <lucas@lucaspardue.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC97C151981 for <quic@ietfa.amsl.com>; Mon, 26 Feb 2024 09:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=lucaspardue.com header.b="aZWeqt9r"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="V4oqOqb0"
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 0lJzNkpuY40T for <quic@ietfa.amsl.com>; Mon, 26 Feb 2024 09:54:29 -0800 (PST)
Received: from fhigh2-smtp.messagingengine.com (fhigh2-smtp.messagingengine.com [103.168.172.153]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 72D00C14CEE3 for <quic@ietf.org>; Mon, 26 Feb 2024 09:54:29 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 7D6DA11400A9; Mon, 26 Feb 2024 12:54:28 -0500 (EST)
Received: from imap53 ([10.202.2.103]) by compute3.internal (MEProxy); Mon, 26 Feb 2024 12:54:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucaspardue.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1708970068; x= 1709056468; bh=1ABSxthQ7FC6vHkfLAG3JocYe0qfYTObsECMFemJ5GQ=; b=a ZWeqt9rz7PmK4u6kqtwokxG5CrqzCWYfE5jsLNHMCbMjA53eCkP/9hQf2wV2BkU+ aIUgEtKVbyw8zKGm37DX2OHiIb0JNyauzgNvLh/XRj1bdwiFrFJrsXQuUON3c7+C z80eEDE/sVOOWUIobxVXRim1vtF/dfTQ8COt44ICO5GgiiS8r0JO8S68eNHQQDwT ve+Fp0hWotQ/AM3kRQC/oY0ZSM6HkUX4OVz5yo23qltVotW2rPbH8USZHurrGdrx nWR2T4j/eS33yz4StQqfuJd14oDoCGIM3pqOHxoyX5Rji/ed0RFF4/7E1+NQnB93 UacbiKLHQDxNhzu0/wYTQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1708970068; x=1709056468; bh=1ABSxthQ7FC6vHkfLAG3JocYe0qf YTObsECMFemJ5GQ=; b=V4oqOqb0uCHbwxugEGfi5AKeGkkWr5rEe5ZbIdtYb24u dn3pTpGyejY58Z94Zn6jnLxAAAp23rz+w9AwKlRyExhOb1uOM2D5RTp9DwfrKHW2 HdfFJAVTS+LR4MgcDvyK3Vi7kwFRzrlmZQ7haZ7AsGXg8bgrZpsg0FwszpooLLrA gxLZLFZYIpWEY0Z4aDJ+zdhnYQ/PQa4DfWwUpnyn+VvH+532s+7ye+Iq3UyaWI4o HCjKDHH9TtFNGClIyoygGIUA+y4+V3GzfeuTRLsX+SXC2e6JLFZ01UDzFRnTRUiR diKVOtAgQ4gq+R4kvCQq8Fa3bChRlwWrs5qsxw/sbA==
X-ME-Sender: <xms:VNDcZUcfKJEL2EDlMA81UyQrnFsqPAeEyRzqSR3EWnVfSnNpxzGfAQ> <xme:VNDcZWM3mYlgAE_jMEk8m7hpnt6QBsoApkHyiDx4k2A2wF7CBz8v_iwhvqLUqPmOf rFPhPzlW2Cn5jI2PP4>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrgedvgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedfnfhu tggrshcurfgrrhguuhgvfdcuoehluhgtrghssehluhgtrghsphgrrhguuhgvrdgtohhmqe enucggtffrrghtthgvrhhnpeehteeuveeigfekfedvhfevieefjeejfedtheekjeejffdv lefgieelueeutdeljeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhhutggrsheslhhutggr shhprghrughuvgdrtghomh
X-ME-Proxy: <xmx:VNDcZVjfox48jDc_7by9G2gxLeNqQqniXbV87eFgfCnomQN-TvCo3A> <xmx:VNDcZZ-UcsBPK3zksjsw9aLVLNgKaZ_zlJUobGSjIb5uVvHXXHPTmA> <xmx:VNDcZQvmJwOFUvc6St5FD2IQnGjN4-fGFzVwPqcGarOXPbSE3F5XZw> <xmx:VNDcZSKvF_bMbtcZkEvcyfct_JvHI4GCrzXMQyC_IpI8oxjLOuqmxQ>
Feedback-ID: i23b94938:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 31CF43640071; Mon, 26 Feb 2024 12:54:28 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.11.0-alpha0-153-g7e3bb84806-fm-20240215.007-g7e3bb848
MIME-Version: 1.0
Message-Id: <5af8e069-1778-420d-be21-88be223fdb29@app.fastmail.com>
In-Reply-To: <SJ0PR15MB4693CB50BAF995140FDA8200D45A2@SJ0PR15MB4693.namprd15.prod.outlook.com>
References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com> <93FF52D7-53DD-4B72-A54F-EF952F7B5054@eissing.org> <SJ0PR15MB46935068A5E9F9B4288FAB57D45A2@SJ0PR15MB4693.namprd15.prod.outlook.com> <63c9787e-3e76-4a47-80e3-ba4d7f3a9d2f@app.fastmail.com> <SJ0PR15MB4693CB50BAF995140FDA8200D45A2@SJ0PR15MB4693.namprd15.prod.outlook.com>
Date: Mon, 26 Feb 2024 17:54:07 +0000
From: Lucas Pardue <lucas@lucaspardue.com>
To: Roberto Peon <fenix@meta.com>, Stefan Eissing <stefan=40eissing.org@dmarc.ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Proposal Towards Universal HTTP/3, with a polyfill of QUIC for TCP (Fwd: New Version Notification for draft-kazuho-httpbis-http3-on-streams-00.txt)
Content-Type: multipart/alternative; boundary="75a31f09b3f14329b8e0de97a1b447a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/qQNfXYhkGLasN2Fm8JITO5i54xo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Feb 2024 17:54:34 -0000


On Mon, Feb 26, 2024, at 16:38, Roberto Peon wrote:
> 
> To avoid deadlock with TCP or TCP-like things, we’d have to guarantee we could always read (what is for QUIC and H3 async) control stuff from the socket, which would require always reading all bytes/frames sent on the socket, always.
> 
> I’m unsure if that same text is sufficient (haven’t thought about the conflicting congestion control stuff), but it is certainly a good start. I believe it might be sufficient for effectively tunneling H3 over TCP… probably. Certainly it wouldn’t work without said text.
> 

Agreed. We're close approaching IETF document deadlines so I'm not sure we'll have enough time to address things fully. I create a GitHub issue so we don't forget - https://github.com/kazuho/draft-kazuho-quic-quic-on-streams/issues/9

Cheers,
Lucas

v2.23.0 | Report a Bug | By Email