From nobody Wed Jun 23 13:13:48 2021 Return-Path: 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 72CDA3A3EEA; Wed, 23 Jun 2021 13:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MSwAA8XmNzd; Wed, 23 Jun 2021 13:13:44 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F79C3A3EE9; Wed, 23 Jun 2021 13:13:43 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id v3so4999431ioq.9; Wed, 23 Jun 2021 13:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kgfqabQmV9aaUNhyVEt06zNVkaRnzbzlxheiIUp4hTI=; b=AUWbf6rxutrKZfOoh8DMNlJB2SKDKmDTT9iq/rXLHVFQ7NfDdlIHv0OAcDIZWnf0pN IECULFMxIRZ7zGKH00ZqagdeLDN55fyU+YVbGkNZSj9YSjaKvHDVfWSXpe+U5pQcfcfk gQvqxz1BJynoQB6uv4bkOf21rdhgdxs5tPLBysc8ILqE7vhVImo7LS6itxj4k5K6Xiak Farr4zS2rKi8LnMQObN+avFubAGMMY1ixQ1ODPmwAMLKsSwZPSvFpyOfsC5TQYmioQSx /jKdl/ztvZk0CZn2NhgdtsoP8lfO5lMhHIKVYWe3Jk5DgqewMMv2lVzE9vikXrg2+bdq BE7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kgfqabQmV9aaUNhyVEt06zNVkaRnzbzlxheiIUp4hTI=; b=DiPbPqHeWee4N2+X/j5MW8qfzOKHHhIA6XrJeCU4sU2LKfisM6EP1xNtKqG4XlGmOo dDi2lKaalld7Dg6yTc36aUP91nTxsGWpFoEyuDTSI1k3Vn5eXEp9Rq39gv4GcyloEtTo 4ZjTiPzbklD8xXH6DWszeCLxai8RM/BSqxclgpz/67hQZ8mwH/C1yGlmWPQWjtd0q/v4 PUxc1lFgbnoQKG59SCa/Bju8wwOvq+1c0U+dJqStygeujk0nW0KYEd+rhFh4akSxuX5Y S3IBvH7qoo9QsBPJdwWkGo158PwnPbAymCBkQ29SdwXscI7z5AUVA8CiteCw2jSNWACn Q2yw== X-Gm-Message-State: AOAM533xcbvfw9dr1D0x4O9IhKlFnq9nsK+Drw6MqSzBjinMa6DQl+Ct x9q1fFvnUQlE2foUCCVpk0hgLWY1qXXbbcHOsdo= X-Google-Smtp-Source: ABdhPJw91hshXPJNq16V3M1rHWJ1SA5BFZN3w95oFIjqCyoqKp3ujAURRs5tQznZC5YaYQpsy+bTU9+XxF+03K+xiXU= X-Received: by 2002:a6b:e50c:: with SMTP id y12mr1112675ioc.20.1624479222196; Wed, 23 Jun 2021 13:13:42 -0700 (PDT) MIME-Version: 1.0 References: <53BD22F8-2BAA-4F9A-9673-77AD781C2EDD@gmail.com> In-Reply-To: From: Martin Duke Date: Wed, 23 Jun 2021 13:13:31 -0700 Message-ID: Subject: Re: [Masque] Prioritizing QUIC DATAGRAMs (was: Re: Prioritizing HTTP DATAGRAMs) To: Lucas Pardue Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Patrick Meenan , MASQUE , Samuel Hurst , Spencer Dawkins at IETF , HTTP Working Group , David Schinazi , QUIC WG , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000fbf56305c5748a5a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 20:13:47 -0000 --000000000000fbf56305c5748a5a Content-Type: text/plain; charset="UTF-8" Lucas, Assuming that we have the necessary language about QUIC APIs, as I've just proposed, to enable something in future, then I personally have no use cases or strong objection to punting. It is somewhat annoying to have a draft for priorities, datagrams, and then priorities-with-datagrams, but if writing the last bit will be a struggle (which I have no informed opinion on) deferring it is probably the right decision. Now descending into the weeds: > It's easy to say this. The difficulty comes, as an implementer, with knowing what to actually do with the information. Concrete example, if a client signals "incremental false" does a server send all streams as FIFO and then all DATAGRAMS as FIFO, or does it look at DATAGRAM flow creation order No, I think the DATAGRAMs correspond to a stream and they go with the STREAM frames in with priority. Whether one delivers STREAM or DATAGRAM first within a particular stream maybe doesn't need tight specification; if we do, I'd say STREAM (if for no other reason than to deliver the headers) and then DATAGRAM, unless STREAM is being flow-controlled. As datagram flows don't have a 1-to-1 mapping with requests and responses, I think streams are the correct abstraction for datagram priority, not flows. If there are multiple Flow-IDs associated with the same stream, they all get grouped together for priority purposes. --000000000000fbf56305c5748a5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lucas,

= Assuming that we have the necessary language about QUIC APIs, as I've j= ust proposed, to enable something in future, then I personally have no use = cases or strong objection to punting. It is somewhat annoying to have a dra= ft for priorities, datagrams, and then priorities-with-datagrams, but if wr= iting the last bit will be a struggle (which I have no informed opinion on)= deferring it is probably the right decision.

Now = descending into the weeds:

> It's easy to say this. The difficulty comes, as an implementer, with=20 knowing what to actually do with the information. Concrete example, if a client signals "incremental false" does a server send all stream= s as=20 FIFO and then all DATAGRAMS as FIFO, or does it look at DATAGRAM flow=20 creation order

No, I think the DATAGRAMs corr= espond to a stream and they go with the STREAM frames in with priority. Whe= ther one delivers STREAM or DATAGRAM first within a particular stream maybe= doesn't need tight specification; if we do, I'd say STREAM (if for= no other reason than to deliver the headers) and then DATAGRAM, unless STR= EAM is being flow-controlled. As datagram flows don't have a 1-to-1 map= ping with requests and responses, I think streams are the correct abstracti= on for datagram priority, not flows. If there are multiple Flow-IDs associa= ted with the same stream, they all get grouped together for priority purpos= es.
--000000000000fbf56305c5748a5a--