Re: Deadlocking in the transport

Jana Iyengar <jri@google.com> Wed, 10 January 2018 22:39 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 77CC0126BF6 for <quic@ietfa.amsl.com>; Wed, 10 Jan 2018 14:39:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, 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 USH0Tcw3lquP for <quic@ietfa.amsl.com>; Wed, 10 Jan 2018 14:39:26 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 A5E131205F0 for <quic@ietf.org>; Wed, 10 Jan 2018 14:39:26 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id c78so246761ywb.13 for <quic@ietf.org>; Wed, 10 Jan 2018 14:39:26 -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 :cc; bh=UmGbE9b6VaoIvF5y0c/5hsaFe7BDVYo8se6uH4sO5Xg=; b=FHfZnJLZEQQAnXB0mYMdmRTyYM5mU6BGRCI4wdWWdV391DC1bmoREowLi+17/a8LoT MlnXoLpLoH78w/dnZ0dc9CVw0QpCl7SeJ+WKoVE8GdpVYJ/SapKgqLZXNf9E50SeDTbe baLIY25S3UlYjulz1ce2+IvUCWNW2OAqbQmO4k3plLGsGvq62qn9T+oPWXhfPApDf3nN HQUOyHwrj0/UChmpehkixsub3qBVLRS9Jzu/CqOZBJx/wcGPpXNAn+2PhlzLIQnB/k3N AB6vkOnnlU5l/u9iAAL18bCzf2whyp40glSGyiIMh7UXvFQKQVrNodZHA6yss703WwKK S7Ew==
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:cc; bh=UmGbE9b6VaoIvF5y0c/5hsaFe7BDVYo8se6uH4sO5Xg=; b=KCH4Sxd6VrCbmU7CidXInuvYGgHIeS9fd77TZwv33O0/aIG79LchkVx5HQrmKkgJvB BpDkEWTq1TQ+3gm+jtzQI208h7eQh6ZlNPjW8WAxQRHNnEzeK7+F7tC3ejrZmLgIsxa0 4QErw+rj2e8pn2l1Jt57ELchtPesrr9YUC7EJH3bUeg6xXjmhelEX2Ihg85Bsnmhptsa jsl9vkmIw+HJNkkpks016sX1hKZey4ps+9onQurrDPBnUr7SaqIaLg3s6yBHf/lBtjGn C10HPp0XxtQOkjFpvgD8PC/sy3l7EqNUt12SMR7EZtAMSqG3t3DVFqM/RF1UmiIUDsIg wo1A==
X-Gm-Message-State: AKGB3mJONFOJczF3141t6PBzbbJse7RIcyQ0jImHiupyjghvb7pYw82u +7QEeo547DJHSCPjHvQfSDs2CVbMu9tQZPRZnPOdlQ==
X-Google-Smtp-Source: ACJfBov3VcOV4HGUL+WK4jjNUTTOXQgQyDrSUT6tReQIYwoAuWDllfubfBj91fPc5O7piOdqe3Q1aoU0k3/wskj14Eo=
X-Received: by 10.129.146.86 with SMTP id j83mr17612666ywg.256.1515623965399; Wed, 10 Jan 2018 14:39:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.42.147 with HTTP; Wed, 10 Jan 2018 14:39:24 -0800 (PST)
In-Reply-To: <CABkgnnU3CQkvd7m+G80sCOPJfzb_=HonbRDSQJC8wqD_uWoj0w@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> <CABkgnnU3CQkvd7m+G80sCOPJfzb_=HonbRDSQJC8wqD_uWoj0w@mail.gmail.com>
From: Jana Iyengar <jri@google.com>
Date: Wed, 10 Jan 2018 14:39:24 -0800
Message-ID: <CAGD1bZbrtMEJE-OOXqG02yWmHy_2baEvaZu=rFCBTtcq94JrOg@mail.gmail.com>
Subject: Re: Deadlocking in the transport
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "Charles 'Buck' Krasic" <ckrasic@google.com>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c08fc8612fe5d056273b499"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/MqUUdZYDUMFcHhpIeAYr_hvoTvg>
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 22:39:28 -0000

On Wed, Jan 10, 2018 at 2:08 PM, Martin Thomson <martin.thomson@gmail.com>;
wrote:

> On Thu, Jan 11, 2018 at 7:32 AM, Jana Iyengar <jri@google.com>; wrote:
> >> What would this advice be?  "Consume *all data* from higher priority
> >> streams before consuming data from lower priority streams?"
> >
> > Yes, to avoid deadlock.
>
> Priorities in h2 were always guidelines.  You (and I think Buck as
> well) are suggesting that a dependency would be something that the
> transport could be bound by.  That creates a dangerous schism between
> interpretation of priorities.
>
> In h2, if Y depends on X, a server can still send Y first.  It will
> likely do so if Y is ready to go before X.  That is, generally, h2
> favours forward progress over strict adherence to priority ordering.
>
> I agree that the case that we're talking about at the transport layer
> is substantively different, but if we don't have other language for
> what we're doing, we create the potential for some really bad
> confusion about this mechanism.  This is exacerbated by the fact that
> QUIC doesn't have any concrete priority mechanism built in.  QUIC
> depends on the application protocol to feed it priority information,
> and that naturally tends toward having hq (and h2) dictate priority.
> hq will likely use the h2 idiom, which won't fit well with this
> notion.
>

Yes, I think there's easy misinterpretation here -- something I realized
today as I've had conversations about this. What I meant was specifically
at the API between the app and the transport, at the sender. This is
basically saying that to avoid deadlock due to dependencies across streams,
the transport write API must allow the app to express strict priorities.

As Buck pointed out, I think this is an extention to option (4) in that it
is useful when data beyond what's allowed by the flow controller is
buffered at the transport sender.