Re: Deadlocking in the transport

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 10 January 2018 14:53 UTC

Return-Path: <mikkelfj@gmail.com>
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 52C4312751F for <quic@ietfa.amsl.com>; Wed, 10 Jan 2018 06:53:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 mua9CUy8huqL for <quic@ietfa.amsl.com>; Wed, 10 Jan 2018 06:53:27 -0800 (PST)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD51E12700F for <quic@ietf.org>; Wed, 10 Jan 2018 06:53:22 -0800 (PST)
Received: by mail-it0-x22e.google.com with SMTP id r6so16469795itr.3 for <quic@ietf.org>; Wed, 10 Jan 2018 06:53:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=nXYVc896YUXxJqJ50LJDgAqhkSmjdMFlwj8Xr/lxeUI=; b=p6DxBdgm5B1t5lqZa0DmcmqxOWJJ1BQCnfTeGdoUuktbbyW0wl3C7+5Z1JXZr5wHjK b2wbXigCnez4i/a+zSt8QFx77aFHE1VDLQ814K5tMqG7phf2/vE3nRQPkXpUuRbujlxj AkALDuBC2+AjfiINUUI8ycgb77c2NTkMH/3IGdIKJNwU75XYAiuCREl5YVkM2boKGYR8 vVRZwkM7Cce+p0cc8ODhzd4nJ0t+Vg59FJKReyelZMVF4GA3l+7JC1lfsTU0BaneiG46 hsPzn9KP57UGiygJ/z7Q5WtLtcaUwpBng+jA/9EDhw/gnrG7W+ap6PPt8f3jodM66Vk5 DiBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=nXYVc896YUXxJqJ50LJDgAqhkSmjdMFlwj8Xr/lxeUI=; b=dZ0nnF67CIrdkbitcO8FYelANnssBkvlm34ezMpwA9y7cJb+uNN16359Np3hTDHz9F 4CB+kpp0zhEcpGI/MpRaiS88dUwzxP0kQcWopn+V99Yywj2iP5DP5KqD5XnoBSxZPG5+ MCCdPsi5i4THXHhbhktx7SwMhLxrgyhNn79+Iq0cNfpbUkUuIi2xpuBGeGUFyx+CFEf0 ITqtwZu619PaVjjcSPIMHL6FVz9LvAA2lCxhIElHSofWwQ2HC2+JPb0Ykg6Bn6V6gKvk NSQmvUNcJoI3zRTFNYay7vpvvAf6c7QV80AhcV20b5NybQzzekMyPF0ZwreBkZf8yj0Z u5VQ==
X-Gm-Message-State: AKwxytfPblUo0Drq+6q2qB4wHDYDNwjEfEIAKBjF69JkWtDSyq4ypNQC 2TNQ8/bgNU1wcT6sJcrx0zDjRpVtgRpeoeHEOv4=
X-Google-Smtp-Source: ACJfBovsVwLo0FbYSfYE78p89GRAHmqlF/oZL2iP4bbS2Z7kROF6VN8IdZG4f1AV/X+IyygJVsO045k6Cc/Oe/mONoA=
X-Received: by 10.36.188.198 with SMTP id n189mr12565235ite.91.1515596002254; Wed, 10 Jan 2018 06:53:22 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Jan 2018 06:53:21 -0800
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <CAN1APdde0eJihUhsOW2b7aVT3Vmi4Cc_Q9dwymEtK-kRbdT3zg@mail.gmail.com>
References: <CABkgnnUSMYRvYNUwzuJk4TQ28qb-sEHmgXhxpjKOBON43_rWCg@mail.gmail.com> <CAGD1bZYV7iHg_YarUMqUSnpbAB2q8dwEWO=dHE2wbw8Oea_zfA@mail.gmail.com> <20180110070542.GA27331@ubuntu-dmitri> <CAKcm_gNR30tNVR6hBH7T46+AXsu42e7-Mo6m8ye1sPwkt_WLEQ@mail.gmail.com> <CAN1APdde0eJihUhsOW2b7aVT3Vmi4Cc_Q9dwymEtK-kRbdT3zg@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 10 Jan 2018 06:53:21 -0800
Message-ID: <CAN1APdcArmwUJ6sOX8hp9mAHc18b4=VS=4nRSWWrsX8O5JQkGA@mail.gmail.com>
Subject: Re: Deadlocking in the transport
To: Jana Iyengar <jri@google.com>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, Ian Swett <ianswett@google.com>
Content-Type: multipart/alternative; boundary="94eb2c11416056698005626d3158"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/LWglXBN95eEAjmx0LHSI0cItvYQ>
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 14:53:33 -0000

For what it is worth, my APACK-02 proposal attempts to solve the problem by
blocking at source, but only for this particular use of QUIC.

https://github.com/dvidelabs/apack/blob/master/apack-02.md#encoder-blocking

If the header compression overall ensures to not use more than certain
amount of credits before blocking, and if the other streams make sure to
not consume any more that the overall credit minus the header block, then
this should suffice from a cursory view.

As to my previous example with large files, the api needs to have some sort
of resource management to ensure background feeds do not over allocate. An
actual complex stream dependency scheme is probably not a good idea, but
streams could be divided into resource groups with allotted bandwidth.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 10 January 2018 at 14.51.26, Mikkel Fahnøe Jørgensen (mikkelfj@gmail.com)
wrote:

Blocking at source is not practical if feeding several very large files via
a mmap pointer to the API for deferred round robin transmission so all
files get equal opportunity to get through. In this case only small pieces
could be delivered at a time before the allocation must check if there is
are more transmission credits.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 10 January 2018 at 14.46.36, Ian Swett (ianswett@google.com) wrote:

I would agree that #4 is the right direction.  GQUIC also does #4, because
it forces all headers to be written before any requests that may depend
upon them are written.

If the application knows there is a dependency, it should be the
application's responsibility to deal with it, not the transport's, which
also points to #4(or maybe #1).

I also think there are use cases for data transfer that is not a stream and
does not consume flow control, but I don't think they solve every problem
and I don't think they should be necessary here.

On Wed, Jan 10, 2018 at 2:05 AM, Dmitri Tikhonov <
dtikhonov@litespeedtech.com> wrote:

> On Tue, Jan 09, 2018 at 10:49:28PM -0800, Jana Iyengar wrote:
> > Protocols that create inter-stream dependency should be able to express
> > that in priorities down to the transport, which I believe is expected to
> be
> > part of the API. I believe that handles this issue, doesn't it?
>
> When it comes to priorities, the QUIC I-D gives implementations
> some leeway [1].  One cannot guarantee that a conforming
> implementation will not deadlock.
>
>   - Dmitri.
>
> 1. https://tools.ietf.org/html/draft-ietf-quic-transport-08#section-10.6
>
>