IETF Logo Mail Archive

Re: Deadlocking in the transport

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 10 January 2018 20:40 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 8A2021271DF for <quic@ietfa.amsl.com>; Wed, 10 Jan 2018 12:40:59 -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 vaxI7KuV3VCq for <quic@ietfa.amsl.com>; Wed, 10 Jan 2018 12:40:57 -0800 (PST)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 108C3126E01 for <quic@ietf.org>; Wed, 10 Jan 2018 12:40:57 -0800 (PST)
Received: by mail-it0-x234.google.com with SMTP id 68so946475ite.4 for <quic@ietf.org>; Wed, 10 Jan 2018 12:40:57 -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=OsSsnz8XJBD9j3/nhNOqi6sqk+E3vnxsxo9CPvlJ+K0=; b=hc+Un0spA+D13dtsFZmZvqgdCpmbXO9+WxNeIcpDQ0m/ym2vNvC5BPEabrvVQLElEu gsVZR4tD3US8iIUstxsjrH4+9w9++zOyiyTomtyT3ORdX5ECNKbW80YuUxdAWtbaf1/z 9szmzZcx9enA1qr2tVWv9De+SCZBOd1xraRrFCCJ7CKFxHys2U1vShaawIfI3OM9RG2B 2r2HqUqxWGPfWBrUfljUWUqnb7XkkXVdI92Qz1QMBEw2g0m98GFAjk4RLIaTAXBJc6Hu SgMaxoS+i3yU/hGZ9xaV1dodrL0TUnDWbieVD6TSTj06+ofU7CynIQttM7wikAxTGNaR HdpA==
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=OsSsnz8XJBD9j3/nhNOqi6sqk+E3vnxsxo9CPvlJ+K0=; b=llQnrEsGq9Wh/J1iUWmlL7cB3SmIuCgy44RdAallCkJQDMrJOg4HkR7p82H8cTLw0t HR/4kJ62qdASWflz5252vWeUaHmY8qvGOy6ttVsPb8/oFSR74EjfhdmRCCUtJENvip5J hhJrAZL3DpPXzKXPk/vxzfbYrsYpdSDrrnNhLchx1HqR0vEDpG5BuRbkc1RSLTYlFnLh sufLpIP7n3UStKm+gIJdpM6Cwx/DXy0U9SkAo0f3L6h0nvLMappppi6pPgw5M0p8wR7e 9p3LQUXxwF6E8bv8D+SDiH0hZ2BluK1eqO89tO62PtXgqTq1PLKkOAUI2qm8vUhCt/zB ftzA==
X-Gm-Message-State: AKGB3mJ+8T/hh61/G1Lh30hFzwjrThQIz8iB9DxEiKuYkIU9q4ZZDvvY 2wtTg5O6ymZfpz2eL62kfmOHMukeBcTDZfXB0RY=
X-Google-Smtp-Source: ACJfBovMWGhGAAlV7gbObDh/YzAk6DYmH9t8cqyAw5ocigISB/bnXvvPefsXSARzdYpfZZ3NAG7itmCshSt1MxP0F8A=
X-Received: by 10.36.181.4 with SMTP id v4mr19269777ite.42.1515616856496; Wed, 10 Jan 2018 12:40:56 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Jan 2018 15:40:55 -0500
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAGD1bZbPM3wnatLLN5938wGPo3e1qmxnGzobSTym6XX3W8FNJQ@mail.gmail.com>
References: <CABkgnnUSMYRvYNUwzuJk4TQ28qb-sEHmgXhxpjKOBON43_rWCg@mail.gmail.com> <CAGD1bZYV7iHg_YarUMqUSnpbAB2q8dwEWO=dHE2wbw8Oea_zfA@mail.gmail.com> <CAD-iZUY-Y-MO_T74JmP6B9XVj=91eVovfcWnE=9s9kd0Ji+CnA@mail.gmail.com> <CAGD1bZa7ugOTT11qOKfCm4NFdi+t-pdrXnscWHgg0bO5tgUqmg@mail.gmail.com> <20180110194716.GA30573@ubuntu-dmitri> <CAGD1bZYiDOakLYNppMBr=99JreX3Xr2zkS7O2DRNfvr_o0NUbg@mail.gmail.com> <20180110200646.GB30573@ubuntu-dmitri> <CAGD1bZa-ZOw5J6oSWBYdk3uYHOpGvak+vwGp0XsZB44zbLvRrw@mail.gmail.com> <20180110202357.GC30573@ubuntu-dmitri> <CAGD1bZbPM3wnatLLN5938wGPo3e1qmxnGzobSTym6XX3W8FNJQ@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 10 Jan 2018 15:40:55 -0500
Message-ID: <CAN1APddt65hXudgRuMOrRJ01GYXTiyMB=NR_P0y=FfTwtK7ZyQ@mail.gmail.com>
Subject: Re: Deadlocking in the transport
To: Charles 'Buck' Krasic <ckrasic@google.com>, Jana Iyengar <jri@google.com>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="f403045d996e58de860562720cd2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/c1PR6wYx1UolYtdXx67oUBSjPXo>
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 20:40:59 -0000

How about a reserve bandwidth function in the API. Header transport could
reserve the minimum needed to ensure a deadlock, and another reserve for
the general traffic. This isolates bandwith consumption from other streams.

I hinted at this earlier. Just like you can share to the total bandwidth
across streams, you can share bandwidth across resource groups, where each
stream belongs to a resource group.

You can provide priorities to groups, but that should not mean the highest
priority takes all. It would be inconvenient and could lead to other
deadlocks. Deficit Round Robin can be applied to groups.

https://en.wikipedia.org/wiki/Deficit_round_robin

Kind Regards,
Mikkel Fahnøe Jørgensen


On 10 January 2018 at 21.32.25, Jana Iyengar (jri@google.com) wrote:

On Wed, Jan 10, 2018 at 12:23 PM, Dmitri Tikhonov <
dtikhonov@litespeedtech.com> wrote:

> On Wed, Jan 10, 2018 at 12:14:13PM -0800, Jana Iyengar wrote:
> > SHOULD is pretty strong. It's not a guarantee, but then a transport
> > implementation that doesn't do it is expected to know what it's doing.
>
> If an application protocol is based on an assumption that the transport's
> SHOULD is really a MUST, then you end up with an application that works
> with some transport implementations, but not other -- conforming! --
> implementations.


I agree, but we aren't specifying the entire API, and I'm not sure that we
want to resolve all potential API inconsistencies here.

> We could include language in this section about priorities being important
> > to avoid deadlocks when an application has dependencies across streams.
>
> What would this advice be?  "Consume *all data* from higher priority
> streams before consuming data from lower priority streams?"


Yes, to avoid deadlock.


>
>   - Dmitri.
>

v2.23.0 | Report a Bug | By Email