Re: Deadlocking in the transport

Willy Tarreau <w@1wt.eu> Wed, 10 January 2018 06:48 UTC

Return-Path: <w@1wt.eu>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B257126CC4 for <quic@ietfa.amsl.com>; Tue, 9 Jan 2018 22:48:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2inkeOQv09Rf for <quic@ietfa.amsl.com>; Tue, 9 Jan 2018 22:48:27 -0800 (PST)
Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id BFC3F126D46 for <quic@ietf.org>; Tue, 9 Jan 2018 22:48:26 -0800 (PST)
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w0A6mKKL013934; Wed, 10 Jan 2018 07:48:20 +0100
Date: Wed, 10 Jan 2018 07:48:20 +0100
From: Willy Tarreau <w@1wt.eu>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Subject: Re: Deadlocking in the transport
Message-ID: <20180110064820.GA13923@1wt.eu>
References: <CABkgnnUSMYRvYNUwzuJk4TQ28qb-sEHmgXhxpjKOBON43_rWCg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABkgnnUSMYRvYNUwzuJk4TQ28qb-sEHmgXhxpjKOBON43_rWCg@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/phqb1eA_DD4gxIcYsQbJ2180yVg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jan 2018 06:48:29 -0000

Hi Martin,

On Wed, Jan 10, 2018 at 05:17:14PM +1100, Martin Thomson wrote:
> 4. Block the problem at the source.  It was suggested that in cases
> where there is a potential dependency, then it can't be a problem if
> the transport refused to accept data that it didn't have flow control
> credit for.  Writes to the transport would consume flow control credit
> immediately.  That way applications would only be able to write X if
> there was a chance that it would be delivered.  Applications that have
> ordering requirements can ensure that Y is written after X is accepted
> by the transport and thereby avoid the deadlock.  Writes might block
> rather than fail, if the API wasn't into the whole non-blocking I/O
> thing.  The transport might still have to buffer X for other reasons,
> like congestion control, but it can guarantee that flow control isn't
> going to block delivery.
> 
> 
> ## My Preference
> 
> Right now, I'm inclined toward option 4.

Well, I'm lagging a bit too much to have a valuable opinion, but all
I can say is that from a protocol design perspective, this option
totally makes sense. Starting to send when you depend on something
which is blocked doesn't make real sense. In fact it could even be
argued that in such dependencies cases, the flow control could be
shared, i.e. Y could offer some of its budget to X to ensure it can
make progress resulting in the two ultimately being unblocked. I know
it would imply a number of painful changes though and I'm just talking
about threory here.

Regards,
Willy