IETF Logo Mail Archive

RE: Deadlocking in the transport

Mike Bishop <mbishop@evequefou.be> Wed, 10 January 2018 22:55 UTC

Return-Path: <mbishop@evequefou.be>
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 2FFF2129C6A for <quic@ietfa.amsl.com>; Wed, 10 Jan 2018 14:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 UWS2cf4tOo2u for <quic@ietfa.amsl.com>; Wed, 10 Jan 2018 14:55:49 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0101.outbound.protection.outlook.com [104.47.42.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65A8129C51 for <quic@ietf.org>; Wed, 10 Jan 2018 14:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h3KbHIk3opF11a4FGiuFV7tIlwKAhZNzPiInt1ARgso=; b=Lwt7qU7EiGOngrTyocMlmmHtHVneaWaH8HDy7q7lT51oo4g3O5wfQpWXdFhDlRYVesAlQ/qS/aDDhiH+kAGYExBKNZhvidfp37m/3jcLNsOmL0MuQGi1SgtFDSrq2IHhMOw5uRclm4mGx4oqhUgeny7vcwpMnOb71YhlOGAopR4=
Received: from CY4PR08MB2423.namprd08.prod.outlook.com (10.168.169.142) by CY4PR08MB2422.namprd08.prod.outlook.com (10.168.169.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Wed, 10 Jan 2018 22:55:46 +0000
Received: from CY4PR08MB2423.namprd08.prod.outlook.com ([10.168.169.142]) by CY4PR08MB2423.namprd08.prod.outlook.com ([10.168.169.142]) with mapi id 15.20.0386.008; Wed, 10 Jan 2018 22:55:46 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Martin Thomson <martin.thomson@gmail.com>, Jana Iyengar <jri@google.com>
CC: QUIC WG <quic@ietf.org>, Charles 'Buck' Krasic <ckrasic@google.com>
Subject: RE: Deadlocking in the transport
Thread-Topic: Deadlocking in the transport
Thread-Index: AQHTidqxAzZR0+xwkEuHcB1dPwao4qNsqpwAgAC3uoCAAB3vgIAAA6mAgAAEuICAAAC5AIAAAhWAgAACuICAAAJVAIAAGr0AgAAIxgCAAADWgIAAATfg
Date: Wed, 10 Jan 2018 22:55:46 +0000
Message-ID: <CY4PR08MB24231DA846126B51A83DC420DA110@CY4PR08MB2423.namprd08.prod.outlook.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> <CAGD1bZbrtMEJE-OOXqG02yWmHy_2baEvaZu=rFCBTtcq94JrOg@mail.gmail.com> <CABkgnnWtmprf291pBgTOrfi6yU9tXSfKi5J5uQpm7Z4JHuiGWg@mail.gmail.com>
In-Reply-To: <CABkgnnWtmprf291pBgTOrfi6yU9tXSfKi5J5uQpm7Z4JHuiGWg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR08MB2422; 7:TucqmBR7Cc67xnabA2mpDCsid7rKehY3kofEgyTI4UICDafE1gG03I0HMzSBgCuHPgKrvEu6TTER3PfcBqsZcwwsmzjr+bux39h4wUFLEi8fT9ncuGtVPn96/OHKUsoBQ7PLX1XZnj8roWN4PiSd8LzIiXvvNjmwEKQMDjSWQFCXhIQjTbkdBCl7HreRQHvmxdoQMyLlQmflXij3T9woRW1kYlo43kLmsNxphbCEpHRIzSTORCGyOaBq5VdrVQdh
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 5a77d8ff-64b4-45e8-2e80-08d5587d4908
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020057)(4652020)(7021087)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR08MB2422;
x-ms-traffictypediagnostic: CY4PR08MB2422:
x-microsoft-antispam-prvs: <CY4PR08MB2422252128C386EDF04F3095DA110@CY4PR08MB2422.namprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(944501125)(3002001)(10201501046)(93006095)(93001095)(6041268)(2016111802025)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:CY4PR08MB2422; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR08MB2422;
x-forefront-prvs: 0548586081
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(396003)(376002)(366004)(346002)(39380400002)(189003)(199004)(24454002)(13464003)(51444003)(54906003)(9686003)(2950100002)(93886005)(305945005)(55016002)(3846002)(25786009)(86362001)(97736004)(316002)(2900100001)(68736007)(74316002)(105586002)(14454004)(6116002)(6436002)(7736002)(110136005)(53936002)(77096006)(478600001)(76176011)(3480700004)(229853002)(81166006)(102836004)(4326008)(8936002)(53546011)(2906002)(39060400002)(59450400001)(66066001)(99286004)(81156014)(8676002)(5660300001)(6506007)(106356001)(6246003)(3660700001)(33656002)(3280700002)(74482002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR08MB2422; H:CY4PR08MB2423.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: dbrHlNu0yzzk9/MzNsC36nqQIwblfZtrSDwxTnsabmkg1x/kvPzrZR/7Ko2Q4BOeCzSSFXoSvL9AKn4w2PLlQg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a77d8ff-64b4-45e8-2e80-08d5587d4908
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2018 22:55:46.0816 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR08MB2422
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/YjJQ62XwQczB0mfncqNtXWyKw_4>
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:55:52 -0000

No disagreement.  When choosing which stream *with pending data* to make progress on, I think choosing the higher-priority stream is necessary rather than advisory.  With H2, we're talking about client preferences about server responses which might not be ready yet, so it's always advisory to the server.  Here, we're talking about the application's preferences about its own data that it has already handed off.  That's something that happened within the HTTP/2 implementation, so there was no agreement or contract needed.

So long as the dependency is strictly on a higher-priority stream and the transport layer is handling priorities strictly when choosing what to send in a flow-control-limited situation, I think we avoid the deadlock.  That is, when X depends on Y, if new flow control credit is guaranteed to cause Y to make forward progress (and the other side is continuing to read from Y's stream), the other side would eventually be able to process X.

This isn't a protocol element, but an implementation element that's necessary for the protocol to be fully functional.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Wednesday, January 10, 2018 2:42 PM
To: Jana Iyengar <jri@google.com>
Cc: QUIC WG <quic@ietf.org>; Charles 'Buck' Krasic <ckrasic@google.com>
Subject: Re: Deadlocking in the transport

On Thu, Jan 11, 2018 at 9:39 AM, Jana Iyengar <jri@google.com> wrote:
> 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.

Ahh, excellent, then I think at least we two are in agreement.  It seems like there is an emerging acceptance of the problem and proposed approach, I guess we might start considering how to address it.

I think that this needs to be in the main spec.  Failing to document this sort of pitfall could be fatal.  Does anyone disagree?

v2.23.0 | Report a Bug | By Email