Re: Deadlocking in the transport

Martin Thomson <> Wed, 10 January 2018 22:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02B45126C0F for <>; Wed, 10 Jan 2018 14:08:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X--P575-TbQq for <>; Wed, 10 Jan 2018 14:08:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B527126B72 for <>; Wed, 10 Jan 2018 14:08:01 -0800 (PST)
Received: by with SMTP id h2so470437oti.5 for <>; Wed, 10 Jan 2018 14:08:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gs2F8Uj8wr489TwYvVXwEGkScZfsamlP655r5GDQshE=; b=e21b+q8Hsw4gP9b5QQILL3IAZO3q9rYHrtRxGeDPX4+e7oBhi6mbdFHG71/5/BiQKL 7O0WiVwRDrkSBLGrafpcw/Kz0YZ/sNcrtiZ6RKz9LgF6UESvNbYPWZL99ndb+E04riRu dJAk1UlDVxr/xVccLUszyqaIzHVxABHV78IV6bMHBnWVLZSVliV+qRN76egU6Mi3ZCcR uCSA+0IwOVRscxtz5dY92xjmv8fh1HAGSQQyiTAlVIqoyvLVyBtbzONyzRDHGIJUlOjG F/nWRiVOAk7C0IqrIG5A84zZZOhcrddjZ3TVm2xGVnLNzDJPQsR03gA8x0o6i/IWuPb4 LHJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gs2F8Uj8wr489TwYvVXwEGkScZfsamlP655r5GDQshE=; b=FEntvrUl0I86otcSMTR4zd03Xhvlz3oG7hxGUcJ3MI+KQeRit7jiy+ipoCnU8AwMGS 9UN4474G9FhIIw3MiWVJyUf+8hADBq1gG3UkTsZXasjC/WLwb2jinKNPwKiwSRy/loVJ YfLuFTTmM6a/6/oC12w7l/9r3ywJYgu6fcqPxaQjmPHTu9P+znpT9hmcEqAyKaYzfne1 8CYVopPYtxAKuErV7AQt3GuBdiEn4wn804oSZG+j+lV6h8po+l+X7mOC6iRf3wGZJGqz WY6omldV7FyVOyatm4s/6ij8+EV3oLk4BmNbunlD/MEhtdbH3hgy/SkolkiS2+bBuR0O 318A==
X-Gm-Message-State: AKwxytePeZ2/1cjWHwX/WlPB5QzjOFfw7vxN5CoL2unkD1BnJ63iNIq+ qF5g1zj54Zsx8b5bv/92v6a+kSFPvK8Svt6zfGQ=
X-Google-Smtp-Source: ACJfBouqbVDHg/CPXseqaZ5ODm5S19hKeTQSQggdz+LMw9AVEyBKSCkLqx6B4NNHwQb4o0SycK4Ovf80NNUgxeReavI=
X-Received: by with SMTP id z38mr12291427oti.16.1515622080828; Wed, 10 Jan 2018 14:08:00 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 10 Jan 2018 14:08:00 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <20180110194716.GA30573@ubuntu-dmitri> <> <20180110200646.GB30573@ubuntu-dmitri> <> <20180110202357.GC30573@ubuntu-dmitri> <>
From: Martin Thomson <>
Date: Thu, 11 Jan 2018 09:08:00 +1100
Message-ID: <>
Subject: Re: Deadlocking in the transport
To: Jana Iyengar <>
Cc: "Charles 'Buck' Krasic" <>, QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
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 22:08:03 -0000

On Thu, Jan 11, 2018 at 7:32 AM, Jana Iyengar <> wrote:
>> What would this advice be?  "Consume *all data* from higher priority
>> streams before consuming data from lower priority streams?"
> Yes, to avoid deadlock.

Priorities in h2 were always guidelines.  You (and I think Buck as
well) are suggesting that a dependency would be something that the
transport could be bound by.  That creates a dangerous schism between
interpretation of priorities.

In h2, if Y depends on X, a server can still send Y first.  It will
likely do so if Y is ready to go before X.  That is, generally, h2
favours forward progress over strict adherence to priority ordering.

I agree that the case that we're talking about at the transport layer
is substantively different, but if we don't have other language for
what we're doing, we create the potential for some really bad
confusion about this mechanism.  This is exacerbated by the fact that
QUIC doesn't have any concrete priority mechanism built in.  QUIC
depends on the application protocol to feed it priority information,
and that naturally tends toward having hq (and h2) dictate priority.
hq will likely use the h2 idiom, which won't fit well with this