Re: flow control and DATAGRAM

Martin Thomson <martin.thomson@gmail.com> Mon, 29 October 2018 22:52 UTC

Return-Path: <martin.thomson@gmail.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 D19E3131028 for <quic@ietfa.amsl.com>; Mon, 29 Oct 2018 15:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3
X-Spam-Level: ***
X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 FAabBixdXKtw for <quic@ietfa.amsl.com>; Mon, 29 Oct 2018 15:52:15 -0700 (PDT)
Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 6AEDC1277CC for <quic@ietf.org>; Mon, 29 Oct 2018 15:52:15 -0700 (PDT)
Received: by mail-ot1-x342.google.com with SMTP id k9so9259725otl.10 for <quic@ietf.org>; Mon, 29 Oct 2018 15:52:15 -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:content-transfer-encoding; bh=uR+k1AphLSWH/7q5Ao7X0MK+D6Aqu/dbjqKhiTd+jXg=; b=edDmmK/L+rzEK4QsYL3auCr73ybsoRlQWDcCG44oQZ5lzvIzO1PZ7tSBokx6Zzsedm 8sbO8QEn4tMcAuRx65Frl14yvbIK88TnY527FmAs4ZN7Vj6fpJDhpaOjTZZy8AgRhXIN xUGSSoiP/FVVI46vzv81QjxDyEPZGYNqjNsfVXHgWoz6cLxZgxZPo8yLtcto2vfftu5C PEcobuPbZFzfOhwuwaVv+G1gND6N9oPInucHvNLMAyhbNC89LXJMyLhJ1/OxziOv7X6e YjgZfRwFsMUyT56uQn862/3/os4QJNE2+3ylB30nJ/QO8WyaWfh397CqCedk7PaHSPzy PLNg==
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:content-transfer-encoding; bh=uR+k1AphLSWH/7q5Ao7X0MK+D6Aqu/dbjqKhiTd+jXg=; b=qlfsDf25gBGgWhWDGQqqcUwf7hIVW1zJ+cD3ntAzsAxlSPT8TN0GtYHky6JT9Lxa+r 4toPLWMICMUC/lN1ajd6HCIVcOZ8lsQAO4v9Qb3kws+Y0RIdUx6wz1CQPQbCXcHUTIL8 DtQ5TyGErhDZDgsjnEicBeYKiaqi4LfQTon9CNNvZE9aFRJBW4BqnBzPEDlw/i2W2exi SxhNH98ABlpsDSO5zhATtmicQ2kQiTz5Zq9msi9hOMAEKAYNDQxyfC6e9Ux3aRJc4tR0 P5BoyGuTZDAnRJ+vJV9CH0wy9mvcwN9ctgaXID3S2R1kl45qW3QoL2WLEvQm03WAQlsq tfzg==
X-Gm-Message-State: AGRZ1gKS3mTe2kItBMgMp6z2a/aDbB/E5c5vCDECSb/2J56NV5eYWxWI 0wLwKEhGklq6lQDUZLwacCkuO6GFXw79yWKjM5A=
X-Google-Smtp-Source: AJdET5e5FOer8EJALNx8Qu+6X8q8Niw9gb/npO9iwER79n8uLjrXboYH2t6PQgqPsYglB93k/qRNJoG5N3UAhb1iEJo=
X-Received: by 2002:a9d:7a48:: with SMTP id z8mr10819126otm.257.1540853534633; Mon, 29 Oct 2018 15:52:14 -0700 (PDT)
MIME-Version: 1.0
References: <CABkgnnU26aYD=TybuD0FZGYtfEa6np-Sk3Jo6t7LRp0wzKh3Lg@mail.gmail.com> <CAKcm_gMDOyJC0AwOo2knN6AMxVbySjGsrLvjcC9A8UA9xcvcWw@mail.gmail.com> <19D3595B-8845-45B6-A60D-9E934DD49FAC@apple.com> <CACpbDcfk+GXb3aL5LG0wQM87thRGO5Y4Q+9cbXf5YuW1=jWCig@mail.gmail.com> <B7BE2454-2A4D-4323-B0A5-0D73BD4B819F@apple.com>
In-Reply-To: <B7BE2454-2A4D-4323-B0A5-0D73BD4B819F@apple.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 30 Oct 2018 09:52:04 +1100
Message-ID: <CABkgnnVsgNU8dm08-UGQZqyMP49KtXyV5bSDrWAto2t3x9VOcw@mail.gmail.com>
Subject: Re: flow control and DATAGRAM
To: Tommy Pauly <tpauly@apple.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>, Ian Swett <ianswett@google.com>, QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/v_Ye1pTpkA_k-Uw_e0ZfO7wCbUU>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 29 Oct 2018 22:52:17 -0000

On Tue, Oct 30, 2018 at 7:01 AM Tommy Pauly <tpauly@apple.com>; wrote:
> I'm not suggesting any changes to when the packet gets ack'ed—specifically, I was responding to Martin's hypothetical of having an ACK to a DATAGRAM frame meaning that the application had processed the frame. My impression is that the ACK to a packet containing a DATAGRAM frame means:
> - The packet made it across the network to the QUIC endpoint on the other side
> - The QUIC implementation will deliver the DATAGRAM frame to application (it won't drop it locally)

That works.  If you allow for the possibility that an application that
is unable to process the DATAGRAM will be indistinguishable from QUIC
dropping it.  That is, if the application can't take the upcall
because it is too busy, then QUIC might not bother waiting.

> Having a separate outstanding data limit for the DATAGRAM "stream" is an interesting solution to the space. It would then have the nice property of not looking like traditional flow control. It could even be measured in number of frames, rather than bytes (depending on what the limiting factors are).

This is something I alluded to in my email.  I don't think that it
improves things much, other than perhaps insulating streams from the
excesses of DATAGRAM frames and vice versa.

If you have a limit, then you need to ensure that both endpoints agree
on its value eventually.  With DATAGRAM, you might think that it's
possible to add a new frame that expresses how much data was sent
(that is the sum of sizes of DATAGRAM frames).  That would run afoul
of reordering problems, where the limit is exceeded when delayed
DATAGRAM frames that are already counted, arrive after the accounting
frame.

You could limit the count to just lost DATAGRAM frames.  That would
allow a receiver to repair its view of how much was used.  However
that runs afoul of two problems: acknowledgments aren't reliable, and
packets can be declared lost and still delivered.  In both cases, the
sender can believe that frames didn't arrive and so increase their
report of "lost bytes" too much.  The receiver ends up with an
inflated view of what was consumed (as opposed to the value being
short).

If you wanted to solve this problem, you would probably need to have
per-frame tracking, which makes this a lot less lightweight than I
think we want.