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.
- flow control and DATAGRAM Martin Thomson
- Re: flow control and DATAGRAM Ian Swett
- Re: flow control and DATAGRAM Tommy Pauly
- Re: flow control and DATAGRAM Jana Iyengar
- Re: flow control and DATAGRAM Tommy Pauly
- RE: flow control and DATAGRAM Lubashev, Igor
- Re: flow control and DATAGRAM Christian Huitema
- RE: flow control and DATAGRAM Lubashev, Igor
- Re: flow control and DATAGRAM Martin Thomson
- Re: flow control and DATAGRAM Roberto Peon
- Re: flow control and DATAGRAM Jana Iyengar
- RE: flow control and DATAGRAM Lubashev, Igor
- Re: flow control and DATAGRAM Jana Iyengar
- Re: flow control and DATAGRAM Ian Swett
- Re: flow control and DATAGRAM David Schinazi
- RE: flow control and DATAGRAM Mike Bishop
- Re: flow control and DATAGRAM Subodh Iyengar
- Re: flow control and DATAGRAM Jana Iyengar
- Re: flow control and DATAGRAM Tommy Pauly