Re: Deadlocking in the transport

Jana Iyengar <> Wed, 10 January 2018 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42E6512711B for <>; Wed, 10 Jan 2018 11:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dc46LfV0lhcq for <>; Wed, 10 Jan 2018 11:34:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3391F1200B9 for <>; Wed, 10 Jan 2018 11:34:13 -0800 (PST)
Received: by with SMTP id z132so45456ywd.9 for <>; Wed, 10 Jan 2018 11:34:13 -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=fWRymcIvApO+itdwS2vGlfKOFrd+ygZxMC8qSCo9/oI=; b=SswZWm5JBnh/3PgJHLyarOlYG1S/WIrUEZ3lT33HjLnJuIO0bRgpbXu4wB0Cdvmk7N A0DVqq/O8bncqd7QfXIWzmL1Oiz/OFer5pmCws09r1I7LjolCS9BKv4f0xVJPcOErGK+ iTUOpFKCi97WwlHDYeueEjiKWWgg8J2qh8IzISsAwLonOpt2t5K4c/ZRWUTR2Y7YlR9n h6MSdXN7IfuQ9s2XxDly1pztntggBd4bb2bd45NR9xokFe6IZooN02IbOqVKteTGW5Bl AFlkHz8FihC2fV7svpGRc55Q/yg4dmqnR5ruqGizhlnqaYtlQFhhDxS8UB6uXFMuKZ0W W1Gw==
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=fWRymcIvApO+itdwS2vGlfKOFrd+ygZxMC8qSCo9/oI=; b=h1XIZMENO/doRLa3UhmxIaFM6Cgnbpdt7GhO/Sa+4OjtDvzLgegc1kb2G/IaRpJ762 sQ5a4yxA3kUC5Kj7NLkEHD7klfJ+4x3IO8A+pW4Fx8ceCF5mQE9OY9TUV92vzJhsZf91 Tryc44mdz7macRNlTKUYueYBrzgbHebwC51vzWWD7OZ2klUHd2KmAHWO9K7CxUnc1kv/ SqtRiOXDoY/E+X3A/7ad+PZTdDmHsZNE8d4kmKbbY1q3sQsPbtPcylIhUJVXltEO3FnM PiRugad1UYN8TKFTngcrl6PgVAzsb4chXCsnacn4t+JNc4avYchcknuFUWIgSS0M2KCZ jpBA==
X-Gm-Message-State: AKwxytf+MTk6oSxQ203l1yvR9rbp5VUbKc7OcvkO1yAy6AisXf7W6exb KiuXbCx4dwjQK6H1G+S9Cs7IIzTEfSkIBwx9o3ulyw==
X-Google-Smtp-Source: ACJfBouwKUl/ki1WSbcnIocwj1K2iNJesJ5gbdDGyXr0SeWwDZENv/Q6UoxC+aXBq6ThpnQIadHR1zl13wqF4sFLOew=
X-Received: by with SMTP id l124mr2605511ywb.139.1515612852068; Wed, 10 Jan 2018 11:34:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 10 Jan 2018 11:34:11 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Jana Iyengar <>
Date: Wed, 10 Jan 2018 11:34:11 -0800
Message-ID: <>
Subject: Re: Deadlocking in the transport
To: "Charles 'Buck' Krasic" <>
Cc: Martin Thomson <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="001a113aa1ecaad6200562711dde"
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 19:34:15 -0000

On Wed, Jan 10, 2018 at 9:47 AM, Charles 'Buck' Krasic <>


I think priorities actually do help solve this in the following sense.   It
> makes a variation of #4.   A write can occur, even without immediately
> consuming flow control, but the priority does ensure it will get flow
> control when it needs it.
> This isn't necessarily HQ priorities though.   A workable, but less
> performant variation, might be to say that if the transport does buffer
> writes, it must service buffered writes in a global FIFO order.

I agree. That's what I meant by priorities solving it -- that the shared
resource (connection-level flow buffer), if consumed in priority order at
the sender, avoids this deadlock. This  assumes that the application can
express this to the transport of course.

With priorities, the part where A sends a partial header seems invalid.
>  The header compression does have requirements that headers be encoded
> strictly sequentially, so partial header write doesn't make sense there.
> The counter example given was a proxy, but I'm not sure that it is
> reasonable to guarantee that QUIC proxies can always be oblivious to
> mapping level semantics.  In the case of HTTP and header compression, it
> seems especially counter-intuitive to me, since most cases will not have a
> 1:1 upstream downstream connection topology.

Yup, agreed.