flow control and DATAGRAM

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

Return-Path: <martin.thomson@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 10EA412F1A6 for <quic@ietfa.amsl.com>; Sun, 28 Oct 2018 22:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ImEW1C0oe-Ud for <quic@ietfa.amsl.com>; Sun, 28 Oct 2018 22:16:18 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 2F55D128D0C for <quic@ietf.org>; Sun, 28 Oct 2018 22:16:18 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id q25so6365351otn.12 for <quic@ietf.org>; Sun, 28 Oct 2018 22:16:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wCB1B1FaNuW9K8XcGHICipdaJL7iV0nBXI0ryft2Vyo=; b=PjL6xfA/xaoelwbLcTJhdIbODM5s9xsxb0v27I/mxogP/MQCko1HBrR8wPYZsjskUO j5VmBn7Z1X1MlvNvyHZ1J4t8yJtcjtw3gsW8taQQp3JAtbI5nAlIxwISqUapP2Hy2pmh fmFnKNv7cUet6/OgCZjVGZrwXhV36u0ORqh17Mk1T22okFqePxpXb1fNQLmsTU0OZm1z opOpiBWgOD1R9Xrch6QQF6p7LZPe94N6HjwN2YuqEeXQqz9yUYayVFCbxn17aEFFN2Bg 1Tua6weFWIToznmTOftXh9QaCXq9NCn9RMvJ5SFU9o+hqFBJt+JGpiCOGzSfDQacUiiU l2VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wCB1B1FaNuW9K8XcGHICipdaJL7iV0nBXI0ryft2Vyo=; b=YRSlWsu5AAw8yqPJWPk2sDG9eHFpWpuCZmh9kmxwlggRcCIMfiOf0s8U0t0OFbDOuu 0wmfHuEHNxREbVJVxLDFwPsZFRHivdesPJ1katmAc9MaTej0PYJibFwsX1l8emhODQvm EbEa9vy2OPvkkWgUnZAAodfjSC/HgGXwSfbFeHfONBCiOymo97akt1u9fvBc5LS8WE4C en4NzpM2nf5tL8KJ3ouXhhpVQlhzgQqh8ADQBkFo+QiMQh2To1rLjy+vBB/rUZnE6092 Glhph5T4sc0mqscGGVogpoyizoEUCuLdi4ZsX9fEPR3aO3Qc/M0Bjl7awASeFdkiUgZW 6esA==
X-Gm-Message-State: AGRZ1gLGAQzcOipiLJrqJ4PfESP+tkdCO8Mxo/cnzHHq+QbLU8HKBsva 4W5ncVHthhQMah5bHy7tTA5yEt5nh/jD2sDeIcA=
X-Google-Smtp-Source: AJdET5fSNQXwmlgaUKBY4NyzKulFPh7rn2qUaqnpJ2Xh4BMUvTA188kHUzID5q+fP+AMIp0ga+x2FhuUqu6SryWXhXI=
X-Received: by 2002:a9d:7a48:: with SMTP id z8mr8573855otm.257.1540790177242; Sun, 28 Oct 2018 22:16:17 -0700 (PDT)
MIME-Version: 1.0
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 29 Oct 2018 16:16:07 +1100
Message-ID: <CABkgnnU26aYD=TybuD0FZGYtfEa6np-Sk3Jo6t7LRp0wzKh3Lg@mail.gmail.com>
Subject: flow control and DATAGRAM
To: Tommy Pauly <tpauly@apple.com>, QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/T8pnq8DVSlf6dyO3C4aPAO4zBKA>
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 05:16:20 -0000

Hi Tommy,

Your slides - <https://github.com/quicwg/wg-materials/blob/master/ietf103/IETF103-QUIC-Datagram.pdf>
- say that DATAGRAM frames respect connection-level flow control.  I
missed that in the draft, and I don't know how they can do that in the
face of packet loss, especially when you don't necessarily retransmit
lost DATAGRAM frames.

For that to work, you would need a bunch more machinery to make the
connection-level flow control sync between endpoints in the case that
packets are lost.  A disagreement about how much flow control is used
causes things to break down badly.  Ian and I discussed this point at
the last meeting and quickly agreed that while it might be nice to
have flow control for this stuff, the increase in complexity is
considerable and (at the time) we thought it wouldn't be worth it.

The problem that introduces is that you could end up having too many
DATAGRAM frames arrive.  The receiver has to drop something at the
point that it can't handle them.  And we say that when you acknowledge
something, you processed it.  That's tricky.

It might be easier to say that a QUIC acknowledgment for a DATAGRAM
frame doesn't mean that it was received and processed by an
application.  An endpoint might discard these frames before passing
them on to applications if it doesn't have space.  In other words,
acknowledgment of DATAGRAM means that QUIC got it, not that the
application got it.  Sadly, that means that the QUIC acknowledgment
machinery doesn't help the application that uses DATAGRAM all that
much.  Also, the lower bound on reliability is 0, which isn't the best
thing ever.

Hard choices, I know.  I don't have a good design for maintaining
connection-level flow control (or any back pressure mechanism with
equivalent properties) that doesn't add both complexity and overhead.