IETF Logo Mail Archive

Re: Deadlocking in the transport

Jana Iyengar <jri@google.com> Wed, 10 January 2018 20:14 UTC

Return-Path: <jri@google.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 2545912711B for <quic@ietfa.amsl.com>; Wed, 10 Jan 2018 12:14:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 lcW3xbeBNi_t for <quic@ietfa.amsl.com>; Wed, 10 Jan 2018 12:14:15 -0800 (PST)
Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 3984C126DED for <quic@ietf.org>; Wed, 10 Jan 2018 12:14:15 -0800 (PST)
Received: by mail-yb0-x22d.google.com with SMTP id a82so110403ybg.1 for <quic@ietf.org>; Wed, 10 Jan 2018 12:14:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=24r5AYcA6zaSkjKYjvoBqpQSvV2B28lI066lc/iMTkE=; b=vNuDohiUiS9MXGvYeuN/RrbvM587YanRVIIWwWK35vV0xIsXLuA+JuHg/9Owuv3ekm 2Y6Ynh5Ar8/f4jFMuVVnmOjc1KMb9noFzI6/Le3YJ57cXzZ6zhvUKIyNvmKrbnim5+Gm 0+EMRG6gd5t/tG+2bPXRLbZ9umGuNfXWSkx9ap9RCAxxvH7XwWY8RSAB7Ny/kzmYwsfE S+Q4tvB75B6IhnM4yuCNNDUtzmKnQDmedrj7B8pDZ4jVjGNz0Z48SXmobqLZ8psSGYLf qJ3pCIsUWOZdKMtPH2K5ILWQDkGJ38ZFWu0Usaykug0xER5eYa9BI42wFfWOJMN5+JlW /E0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=24r5AYcA6zaSkjKYjvoBqpQSvV2B28lI066lc/iMTkE=; b=UoE2wMDMNK7ABhffvhX9EnKG5HqUamL0mCLD7Wfob2wdyCBISRlDHp693AcvTGO+h+ gjapZDuRYtiz8O+G3bfj/T0FY7pq1JbosWHdyd+WHdzGT+dQm6SZdXZ9hhmH0f4/4hxb 6f2WE6C8JM4E5pj9A5pT3D7e1VMVDqbytN954UaE3dyMZ4phEyA3fCmEMSorsTbHHUo1 0AxLpQQfsXbTtqmI3eWHjdNpWrfAYEMEz6krWyWVObYkIVoD1XWy/29tQa+NUlWgyUMU Ll30Ey1aUcwYV2a8Z/2UxOtVkKWHY3MdY1goxWsf5dQd/V7c6ZWf3pLJm2cltNTwzmL3 DwdQ==
X-Gm-Message-State: AKwxyteNRXmGvR8AzEccRYuiRhP9Muj9WMVuV33CydrLdxmYhxjK73HC mkfpT606x6IlzvPdEgoXwQ7xq1C5dQuNtBE8SDGbUQ==
X-Google-Smtp-Source: ACJfBouk4OZ+Xo8498XAHXa8m/ZIOUzVk3OL/Psl99VgTbgABtyZ2P+mQ1itynMsL1tIfvgIUaQHcf/quL8R74t9dik=
X-Received: by 10.37.74.132 with SMTP id x126mr1093598yba.91.1515615254119; Wed, 10 Jan 2018 12:14:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.42.147 with HTTP; Wed, 10 Jan 2018 12:14:13 -0800 (PST)
In-Reply-To: <20180110200646.GB30573@ubuntu-dmitri>
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>
From: Jana Iyengar <jri@google.com>
Date: Wed, 10 Jan 2018 12:14:13 -0800
Message-ID: <CAGD1bZa-ZOw5J6oSWBYdk3uYHOpGvak+vwGp0XsZB44zbLvRrw@mail.gmail.com>
Subject: Re: Deadlocking in the transport
To: Jana Iyengar <jri@google.com>, Charles 'Buck' Krasic <ckrasic@google.com>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a113e652ad729ca056271ac14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rqt3ZDyFS_zQMsr-GKw2uur3NN8>
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:14:17 -0000

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.
We could include language in this section about priorities being important
to avoid deadlocks when an application has dependencies across streams.

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

> On Wed, Jan 10, 2018 at 12:04:11PM -0800, Jana Iyengar wrote:
> > On Wed, Jan 10, 2018 at 11:47 AM, Dmitri Tikhonov <
> > dtikhonov@litespeedtech.com> wrote:
> >
> > > On Wed, Jan 10, 2018 at 11:34:11AM -0800, Jana Iyengar wrote:
> > > > 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.
> > >
> > > Even if the application can express it, the transport is not guaranteed
> > > to consume the data in priority order: see the specification [1].
> >
> > I don't see the text in that section that says otherwise. Under what
> > conditions does the transport invert application stream priorities?
>
> This is the text:
>
>   " When deciding which streams to dedicate resources to, QUIC
>   " SHOULD use the information provided by the application.
>     ^^^^^^
>
>   - Dmitri.
>

v2.23.0 | Report a Bug | By Email