Re: Deadlocking in the transport

Mikkel Fahnøe Jørgensen <> Thu, 11 January 2018 00:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9EA812D7E8 for <>; Wed, 10 Jan 2018 16:09:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4BtEGiOTvSy9 for <>; Wed, 10 Jan 2018 16:08:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB6C1127058 for <>; Wed, 10 Jan 2018 16:08:58 -0800 (PST)
Received: by with SMTP id c17so1380130iod.1 for <>; Wed, 10 Jan 2018 16:08:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=F95DPAs8J6cpqpibOJF5dCPWd1CSWvFawuxgmYffezM=; b=hYrtjjt+Fay8/DNHAdFLyfLHV+sfZ6d+CzqKAxrtJru0fS4ZpvsubufTMH5mIiDh4O cgzQLddnr2vKD2fwVhxNxu5dClLAT5MKwfqN3TjF/adZ2KYqjv1JcX7yffwki52el6ue BaAWExMBxPro319BGc9YeqPHb5vi+rxOyk8FJm+KuQqTjpfLbGLWb3oVNZgMVYlGEhiQ SYPv20geVanMPQWTYOOALN3sbT9NiWIcDmFvHwU6chxpN1D8cu6a4uy1er/9IJEuSvHt WmRO4RrpG3gBYNzlMbdVhuAGeT976LXTgPlppkrZF2ONXAfHOB+DWtMumvL4hNTPKBvC uaNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=F95DPAs8J6cpqpibOJF5dCPWd1CSWvFawuxgmYffezM=; b=arXFur1BdaF6a6YRldQVOHBRDwXzXMgQzThcATPaC9keKsNsXV289IBzbfazH8meRk PdnygGXomjUtaUFwrmRAOurTkZwuRQV+R/DbWjs0Ap2gVF0RcyuuQApC0JaGRF1y/6xw OgTG5HKfDdspjQhmwDsxPYgw8yZbo0nbcOj+mMf5wV0vnHFsiebQzs7PUV0MQ9A/A+rX R46vNAn/wwdw5no28H3DW4zzA3+30VfaU0oHirVlGJGvXhldDNax1y0W3Mj+5/oBbCDl XNnCBz4tzhZuyoin4/PTWenTuWPNfSnaJwwhlMXnsNhdqxGrLqR/8bBbvHNdwOuzuvr3 oeaQ==
X-Gm-Message-State: AKGB3mI0qAPeLZ93Jm04IzT13S/GCtt7UTpJb/KrVtnK8WZxzfIQ3eDw g35c9oe1RkdMMV6Y/xIxsWWPM6/vFSQWOV63Uw4=
X-Google-Smtp-Source: ACJfBoutzOu2yd+HSOBgwOMKvLB1Gyab4zu4GLf02ts0W7Kn4Jmh21pIZieCW5oMWLCSCXtR98SZC4Xd0vK8M7j0BaI=
X-Received: by with SMTP id r70mr19094312ioe.16.1515629338106; Wed, 10 Jan 2018 16:08:58 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 10 Jan 2018 19:08:57 -0500
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
In-Reply-To: <>
References: <> <> <> <> <20180110194716.GA30573@ubuntu-dmitri> <> <20180110200646.GB30573@ubuntu-dmitri> <> <20180110202357.GC30573@ubuntu-dmitri> <> <> <> <> <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 10 Jan 2018 19:08:57 -0500
Message-ID: <>
Subject: Re: Deadlocking in the transport
To: Martin Thomson <>
Cc: "Charles 'Buck' Krasic" <>, Jana Iyengar <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="001a11426b784f20ea056274f450"
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: Thu, 11 Jan 2018 00:09:01 -0000

I’m not sure we disagree, but it is hard to formulate exact.

An example is a bus and 2 car lanes, and a bicycle lane. You don’t stop all
traffic to ensure a bus can get through, but you reserve some capacity for

My concern is that you create a presidential cortege where you close the
highway for all other traffic for some hard to predict interval. It might
solve the primary deadlock but could generate others, and have other
unintended side effects.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 11 January 2018 at 00.59.48, Martin Thomson (

On Thu, Jan 11, 2018 at 9:56 AM, Mikkel Fahnøe Jørgensen
<> wrote:
> I think that this needs to be in the main spec. Failing to document
> this sort of pitfall could be fatal. Does anyone disagree?
> I agree with the idea which I find it important. But I disagree with
> priorities. It should be possible to for lower priorities to communicate
> with reduced throughput which is readily handled by a pacing algorithm.
> There need to be some guarantees for priority 0 though.

See what I mean when I said that talking about this in terms of
priorities is hazard? If you have a concrete dependency, then
reducing throughput doesn't solve the issue. At best, it might hide
the issue by reducing probability.

The language problem is that we can sometimes express a dependency in
a priority scheme, such as the one in h2. This is fundamentally
different to that particular scheme in that it isn't something that
can be fudged or ignored.