Re: Deadlocking in the transport

Christian Huitema <> Wed, 10 January 2018 21:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1680B12DA4C for <>; Wed, 10 Jan 2018 13:07:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.399
X-Spam-Level: **
X-Spam-Status: No, score=2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kiQG1HcxWz5x for <>; Wed, 10 Jan 2018 13:07:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45E8812D950 for <>; Wed, 10 Jan 2018 13:07:02 -0800 (PST)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <>) id 1eZNaN-0004so-J7 for; Wed, 10 Jan 2018 22:07:00 +0100
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1eZNaK-0006mX-De for; Wed, 10 Jan 2018 16:06:57 -0500
Received: (qmail 6764 invoked from network); 10 Jan 2018 21:06:54 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 10 Jan 2018 21:06:54 -0000
References: <> <> <> <> <20180110194716.GA30573@ubuntu-dmitri> <> <20180110200646.GB30573@ubuntu-dmitri> <> <20180110202357.GC30573@ubuntu-dmitri> <> <20180110205006.GA3434@ubuntu-dmitri>
From: Christian Huitema <>
Message-ID: <>
Date: Wed, 10 Jan 2018 11:06:52 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20180110205006.GA3434@ubuntu-dmitri>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: Deadlocking in the transport
Authentication-Results:; auth=pass smtp.auth=
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.26)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5n0uRzd+4d1AZ+3tPm16Fg8Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsSG0P9vnFDCsUxeHeTNBAJB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYd851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Vm3SIdO3BpR97t9bfBi5FxwJWxe4AVanuu6Qx5p47D RY6xvCTKpexH9NiU0GFJBW3GvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATyzYT8K6rd4RA3UMT6Em/UONoJfh+XjGSeeT90H/uIHI a5J8n3XNAXVqVUtf9Gu/ZOooRjA8u8TuHX6ZkKPotGbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW/a7J4lI9dq2HBFg+iT3zKvfFcHV2tQAVqGdj/zM7G/H0fgN5y0tqqfuQuS1mj2Wr5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w
Archived-At: <>
X-Mailman-Version: 2.1.22
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, 10 Jan 2018 21:07:04 -0000

On 1/10/2018 10:50 AM, Dmitri Tikhonov wrote:

> Let's make sure that we are talking about the same idea.  It seems that
> what you are suggesting is either:
>     A. The transport layer not allow the application to read from
>        a stream if a higher-priority stream data is available for
>        reading; or
>     B. If the application wants to read from a lower-priority stream
>        first, the transport layer will pretend that the higher-stream
>        data has been read.  In other words, the high-stream data will
>        be set aside somehow, giving the peer flow control credits for
>        sending more.
> Both seem suboptimal to me -- did you have something else in mind?

The problem arise because of over commitment of resource. Specifically,
it arises if the MAX DATA limit is lower the sum of the MAX STREAM DATA
limits. If MAX DATA was defined implicitly as the sum of MAX STREAM
DATA, we could have a very simple API between application and transport.
The application gives credits on the stream that it is ready to accept
data, and the transport just follows that.

I understand that from a resource point of view it is sub-optimal. The
smaller MAX DATA can be tied to a buffer pool not yet allocated to
specific streams, and there is some possibility to get the application
going with less than 2 bandwidth*delay products of buffers. But then,
this optimization is precisely what leads to deadlock conditions when
the transport does not quite get the priorities of the application, or
when the sender does not quite get the priorities of the receiver.

So we have two alternatives. One is to make the API more "expressive" so
the application can tell the transport exactly which order and
priorities can be applied. The other is to make the API less complex by
just mandating that MAX DATA be large than the sum of MAX STREAM DATA.
Or possibly removing MAX DATA altogether.

-- Christian Huitema