IETF Logo Mail Archive

Re: Deadlocking in the transport

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 12 January 2018 16:03 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 A9AB41270AC for <quic@ietfa.amsl.com>; Fri, 12 Jan 2018 08:03:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 QsVMEjc7xN5y for <quic@ietfa.amsl.com>; Fri, 12 Jan 2018 08:03:45 -0800 (PST)
Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4283512420B for <quic@ietf.org>; Fri, 12 Jan 2018 08:03:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3zJ6xD0QcCzMnc6; Fri, 12 Jan 2018 17:03:44 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch
Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evlHl0OBl63R; Fri, 12 Jan 2018 17:03:43 +0100 (CET)
X-MtScore: NO score=0
Received: from [192.168.178.33] (i577BCE26.versanet.de [87.123.206.38]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 12 Jan 2018 17:03:42 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Deadlocking in the transport
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <CABkgnnWtmprf291pBgTOrfi6yU9tXSfKi5J5uQpm7Z4JHuiGWg@mail.gmail.com>
Date: Fri, 12 Jan 2018 17:03:42 +0100
Cc: Jana Iyengar <jri@google.com>, QUIC WG <quic@ietf.org>, Charles 'Buck' Krasic <ckrasic@google.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EDF23BB9-DA04-44A5-8682-3D22C1DD7380@tik.ee.ethz.ch>
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>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/CXNIt6z3u9Bwm7PoOTKZ1qOg7bA>
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: Fri, 12 Jan 2018 16:03:48 -0000

I disagree. I think it can be good to provide the transport hints about dependencies in application data which then could be used by the transport to optimize the sent-out scheduling, but I don’t think the transport should provide guarantees for ordered processing between streams. For me the whole point of having streams in the transport is to resolve dependencies between independent data.

Therefore, I think it would probably be good to mention this deadlock problem in the main draft but I don’t think we should add strict priorities as a transport feature to QUIC. There are several ways how an application can avoid (don’t have dependencies by using the same stream for dependent data or wait until data has be sent before sending dependent data) or resolve (read all streams and implement an additional application layer buffer) such a deadlock and these should be explained in the applicability document respectively.

My 2c,
Mirja


> Am 10.01.2018 um 23:42 schrieb Martin Thomson <martin.thomson@gmail.com>:
> 
> 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