From nobody Wed Jun 23 07:34:15 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 31F9D3A39D0; Wed, 23 Jun 2021 07:34:13 -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 zIbsLNVr3n8e; Wed, 23 Jun 2021 07:34:11 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 602183A39CF; Wed, 23 Jun 2021 07:34:11 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id hq39so4375804ejc.5; Wed, 23 Jun 2021 07:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=k80QnIPY+kuiNFJkuttUPIR/Am9fcS0OdWdcMaSiSmc=; b=dg8rHcLw/Ez4XFar0HKy7ThJShhDDP1kfre6ojWEEBXLwgJxlZQA/16eZ/xMKGEzAC 9ToNLenHUKKxaCRaOoS4YtrmUa3ZnhuFSGcNtCxRey+hxcK6V6i+7ThsO64Ilge6JktP V/RIfR/TW4O40xKQPDyTNAbTUTufGgbBBMfr4OQgcQD0D5K4ng4aWzNToA9Rg1h9rGso Sjj/J4XiR3I6/rVb5XaCMoJVXrochy04PWIqLLJPCtETo3zteymuGQzeKn7jJRqzIRTZ ODxvxfyJY/pKO7DS6Mh3IBVyL+TzOKfa1e7GahjAta//TQ4wSaqsmHqZgt7yL2OyuS++ 9ANw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=k80QnIPY+kuiNFJkuttUPIR/Am9fcS0OdWdcMaSiSmc=; b=AORIuG4B1UhOcyX3f8OlVrLleRxQ+Fkji9hn3CKnzRzLrs2A197xUA/Uj6jlJP+sfD K0ps3TluAfs0hqhc280LE2U/6ImCZVaVroXw7tNPf3DPEhImmWkSHxEHNYzvWJZrVQay GpWvrBDw68+WX7u4MPrAyc4zT2Jv3b2VxvxBeQYkVPNSqo40o6ZrWeBqLl2Vy+9suTmA 5ve5zIxS+kpDNVWWqDiTQd1/kObggrJr+99vePHVEv3nCORAxgAEIo8WW5rt7yfqihdZ yV3DCaBT1wdkgC94W1CZBPNezvYnzl1VVTkgssTVrEVazyNggHL+foufp8L8O87IJcma IA4w== X-Gm-Message-State: AOAM530+DC2/wGe2sam4HBfYKxjqOcKIXzseiOK3lTWcYIfyV24+D8GY Ir8042v68vXkdtvaYQHw4ek= X-Google-Smtp-Source: ABdhPJxB3/pWKTfCNGU6yfDG4jzjILszl0n3+gTlkwwb7Hd2dNHqqfH1zIJvpXajjz+upO+CTp1S7g== X-Received: by 2002:a17:906:1486:: with SMTP id x6mr330042ejc.69.1624458848524; Wed, 23 Jun 2021 07:34:08 -0700 (PDT) Received: from [192.168.1.3] ([87.72.40.193]) by smtp.gmail.com with ESMTPSA id w17sm7451994ejk.112.2021.06.23.07.34.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jun 2021 07:34:07 -0700 (PDT) From: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Message-Id: <53BD22F8-2BAA-4F9A-9673-77AD781C2EDD@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C1BE6B50-547B-4000-9E30-86CDD1E80A65" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: Prioritizing QUIC DATAGRAMs (was: Re: [Masque] Prioritizing HTTP DATAGRAMs) Date: Wed, 23 Jun 2021 16:34:05 +0200 In-Reply-To: Cc: Lucas Pardue , MASQUE , Samuel Hurst , HTTP Working Group , David Schinazi , QUIC WG , Kazuho Oku , Spencer Dawkins at IETF To: Patrick Meenan References: X-Mailer: Apple Mail (2.3608.120.23.2.4) 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 14:34:13 -0000 --Apple-Mail=_C1BE6B50-547B-4000-9E30-86CDD1E80A65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 Jun 2021, at 15.10, Patrick Meenan wrote: >=20 > Using multiple connections should be strictly worse than streams = sharing a connection, otherwise we probably have a gap that needs to be = filled. Multiple connections kicks the can down to the congestion = control algorithms for each of the separate connections to play nicely = with each other and hopefully result in a decent experience. With a = single connection we should have better knowledge over the overall = transport and make better decisions. For what it=E2=80=99s worth I me mentioned this as a potential downside = when the protocol was drafted but consensus were, as I recall, that the = protocol shouldn=E2=80=99t be designed around overlapping protocols, but = that any specific application protocols were free to document how they = would interoperate. Giving up on datagram IDs simplifies a lot and provides application = protocols with more freedom and less overhead than forcing a specific ID = system. As Lucas pointed out, even if you have IDs there it is not = trivial for multiple application protocols to co-exist. For example, an = application protocol might use all even ID=E2=80=99s for game audio, = and all uneven IDs for active game state and controller data. Then = someone decides to use that protocol to run communication with a remote = controlled wheel chair protocol. But that protocol assigns even ID=E2=80=99= s to left wheel speed, and uneven ID=E2=80=99s to right wheel speed. And = so on and so forth. Instead you would design an app interop header for all datagrams. For = example if the high bit of the first byte in a datagram is set, the = first byte codes for the sub app protocol, and the following data is = then sub app specific. If the high bit is not set, the 7 following bits = is a sequence number modulo 128. Just as an example. Then app protocols = can refer to this meta protocol as a means to coordinate. As Lucas also pointed out, stream IDs also do not work with multiple sub = app protocols, at least not in all cases due to implicit context = assigned to certain stream IDs. Note that stream IDs are not necessarily = handed out in arbitrary order by the transport layer. This might be the = default, but app protocols can require more precise control from the = transport layer, which of course limits the number of usable stacks for = that application. Mikkel= --Apple-Mail=_C1BE6B50-547B-4000-9E30-86CDD1E80A65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23 Jun 2021, at 15.10, Patrick Meenan <patmeenan@gmail.com>= wrote:

Using multiple connections = should be strictly worse than streams sharing a connection, otherwise we = probably have a gap that needs to be filled. Multiple connections kicks = the can down to the congestion control algorithms for each of the = separate connections to play nicely with each other and hopefully result = in a decent experience. With a single connection we should have better = knowledge over the overall transport and make better = decisions.

For what it=E2=80=99s worth I me mentioned = this as a potential downside when the protocol was drafted but consensus = were, as I recall, that the protocol shouldn=E2=80=99t be designed = around overlapping protocols, but that any specific application = protocols were free to document how they would interoperate.

Giving up on datagram = IDs simplifies a lot and provides application protocols with more = freedom and less overhead than forcing a specific ID system. As Lucas = pointed out, even if you have IDs there it is not trivial for multiple = application protocols to co-exist. For example, an application protocol = might  use all even ID=E2=80=99s for game audio, and all uneven IDs = for active game state and controller data. Then someone decides to use = that protocol to run communication with a remote controlled wheel chair = protocol. But that protocol assigns even ID=E2=80=99s to left wheel = speed, and uneven ID=E2=80=99s to right wheel speed. And so on and so = forth.

Instead = you would design an app interop header for all datagrams. For example if = the high bit of the first byte in a datagram is set, the first byte = codes for the sub app protocol, and the following data is then sub app = specific. If the high bit is not set, the 7 following bits is a sequence = number modulo 128. Just as an example. Then app protocols can refer to = this meta protocol as a means to coordinate.

As Lucas also pointed out, stream IDs = also do not work with multiple sub app protocols, at least not in all = cases due to implicit context assigned to certain stream IDs. Note that = stream IDs are not necessarily handed out in arbitrary order by the = transport layer. This might be the default, but app protocols can = require more precise control from the transport layer, which of course = limits the number of usable stacks for that application.

Mikkel
= --Apple-Mail=_C1BE6B50-547B-4000-9E30-86CDD1E80A65--