Re: flow control and DATAGRAM

Ian Swett <> Mon, 29 October 2018 12:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92A7112D4EA for <>; Mon, 29 Oct 2018 05:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v2b_yknswDMl for <>; Mon, 29 Oct 2018 05:32:37 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89666128CF2 for <>; Mon, 29 Oct 2018 05:32:37 -0700 (PDT)
Received: by with SMTP id r10-v6so8482926wrv.6 for <>; Mon, 29 Oct 2018 05:32:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cwrm96QXm00xA09bgoDJgkVf8lY8/xr4fVMtTSEs3Bs=; b=gA5n6HHX7MLCXy4qXoclu/ltefeGumf+9qnuSB/+H8zPLNRCyIHuSAXqki1PBKRYwE UTH3PFb9Uer3XwfaUL4IXPfPmeigZwZQaahpVbsv9naSMem3O4TIBbVoXp5JMptd9QVj /M1nLWkG7MbNbCOlJS3svE9lC/tFzRzbxiDFDcToadV5DJIYYX5d2MZSDFnbbNuho0Md zh83EpkledZpilXmB89VlM2MfDcpiudSg+abU7goh4V5uT7ANdrOl7wtvZkf6a8f7v1e K2WpbKIrxiMmCooIfBYAFg485av1iKcJxLsRi7acxdcH60ItoFrX9tLjacVY3jav6vId ZDSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cwrm96QXm00xA09bgoDJgkVf8lY8/xr4fVMtTSEs3Bs=; b=JA3+nh9zioJpB24DS77YaoQBrjQiOiEJxz0B5J7ahdxhfwnhka4GKHtWIY6otPEIJJ mWNfmsvMp1fHHpBeMPoL5hCuLo1SspdgVqg5xKRuwpGscjTZXFm8xpy9MmvtbcH6uYX2 v7xYC67OyC9Jl+DJ50aHZmQRt+evDEzn2rVDej1B4k7wzre5oVOqCw0y433iJ9rI3s0b to1ae1Qsk02xN+8gvpZnlBuCtci6Kp60AvvN/tpgm2Y5AlOzBolCeFhm4ouG3fZIfK9C a6ijkm3TA40QRm9eez2/NNWqeH6G2JdHaOI6QRe29XQsWqK/IepxJZYh+GVMUxLbQbb0 BqqQ==
X-Gm-Message-State: AGRZ1gI7ygcXetdtqmgxGz8h5M/Omz/Gm9kxmr5/Af37RsjNWkkyTgdY ZdSU+NJL5PCtX1lanBDiGuilK8pe7yga+6KZ8Xo4Wg==
X-Google-Smtp-Source: AJdET5dAkOPZclYWafwDsRKCjcmodzXwen951m+uJpHuc+0vLxPo17RmOeQ6o98Ix6q1M1HkYJ27MtQP4//GcWyfr0c=
X-Received: by 2002:a05:6000:1008:: with SMTP id a8mr14494159wrx.271.1540816355760; Mon, 29 Oct 2018 05:32:35 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ian Swett <>
Date: Mon, 29 Oct 2018 08:32:24 -0400
Message-ID: <>
Subject: Re: flow control and DATAGRAM
To: Martin Thomson <>
Cc: Tommy Pauly <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000008d27be05795d43d8"
Archived-At: <>
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: Mon, 29 Oct 2018 12:32:39 -0000

Good catch Martin, I missed that in the draft as well, and I also think
it's impossibly with the proposed design.

And yes, I think Martin's proposed solution is likely the only practical
one.  In my implementation, the frame is passed up to the application
immediately, so technically QUIC processed it, and it's the application's
job to decide what to do with it.

On Mon, Oct 29, 2018 at 1:16 AM Martin Thomson <>

> Hi Tommy,
> Your slides - <
> >
> - 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.
> Cheers,
> Martin