Re: Deadlocking in the transport

Roberto Peon <fenix@fb.com> Thu, 18 January 2018 19:46 UTC

Return-Path: <prvs=45563d01f0=fenix@fb.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 4D9CE12D7FC for <quic@ietfa.amsl.com>; Thu, 18 Jan 2018 11:46:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=fb.com header.b=P/+Pi30m; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=iBRb7vz2
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 cXxyO7KnAQ-w for <quic@ietfa.amsl.com>; Thu, 18 Jan 2018 11:46:50 -0800 (PST)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA55512D7FB for <quic@ietf.org>; Thu, 18 Jan 2018 11:46:50 -0800 (PST)
Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0IJkjwx027565; Thu, 18 Jan 2018 11:46:47 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=GFv/mhp5p6nvJ3ovFGbhqBxIPRbFq/3hw95IPO9ksrQ=; b=P/+Pi30mrLyakwAHXC5XxNoeVTx3gxymrME8VO3OhYwnjsH6EWuzJwTdBI7wUrBcCn5K rSg3OvI2ULF0SJPTkm6auUeUzfhpMVtKSb5ixgnZj5UMFivmKC8alzPqDzA9wSQ1q4sk NBl8xgpq8DfSVKqLZ/fhePgEwwwRCO6aids=
Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fjyhp0vgc-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Jan 2018 11:46:47 -0800
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.13) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 18 Jan 2018 11:46:26 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GFv/mhp5p6nvJ3ovFGbhqBxIPRbFq/3hw95IPO9ksrQ=; b=iBRb7vz2n16bvqrt0jdvYVe4x0f2KFKOlYPR7zokISZhMzuX5vOQOR38EppBCONT1H/4FbFyvd2npNEVNKnZg1jcW7xWpi9dSLIyphkUYLbZKabV4TEj/r7PbNAHAWLtcRa8zAxHr9Ah4V7NZzDIHiPZTX9OBgcrDfZThJ5BlHU=
Received: from SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) by SN6PR1501MB2190.namprd15.prod.outlook.com (52.132.120.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Thu, 18 Jan 2018 19:46:22 +0000
Received: from SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d]) by SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d%13]) with mapi id 15.20.0366.011; Thu, 18 Jan 2018 19:46:22 +0000
From: Roberto Peon <fenix@fb.com>
To: Martin Thomson <martin.thomson@gmail.com>, Ian Swett <ianswett@google.com>
CC: Jana Iyengar <jri@google.com>, QUIC WG <quic@ietf.org>
Subject: Re: Deadlocking in the transport
Thread-Topic: Deadlocking in the transport
Thread-Index: AQHTidq/6Mg61g6LuEipz9qoFIGKPqNsqpwAgAC3uoCAAB3vgIAAA6iAgAAEuYCAAAC5AIAAAhWAgAACuICAAAJVAIAAGr0AgAAIxgCAAADWgIACtUUA//+auwCAA/jxgIAEpw2AgAAOwICAAJKjgIAASfqA
Date: Thu, 18 Jan 2018 19:46:22 +0000
Message-ID: <40331485-F99A-4CE3-BAE9-D448046620DF@fb.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> <EDF23BB9-DA04-44A5-8682-3D22C1DD7380@tik.ee.ethz.ch> <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> <CABkgnnU+9u3pqzN7QbowAktxwFwj2XqJDhVyB5h5XOszF1CuXg@mail.gmail.com> <CAGD1bZa7L2OzDjf_FUTsQuxpfkRTjs97tCjZkBg9xVcAKqNfhw@mail.gmail.com> <CAKcm_gN2s2c9Uw86Ppb0yGLHXnahSfLBaWG7VoX31Nvut_hBAA@mail.gmail.com> <CABkgnnW=75JxULpKgjO3K8Ry1E2umDq4icYJS3SqetRSMjamAw@mail.gmail.com>
In-Reply-To: <CABkgnnW=75JxULpKgjO3K8Ry1E2umDq4icYJS3SqetRSMjamAw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c090:200::6:1ae7]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2190; 7:q0Fi7CgLWJhYpeRbXanXRDF62tePdLCusLDwjSCjHRdLwkMmoQ7s3cNGUiyopSfpo42bvJoZkf3zk3pPo61C3vRRxH+Xf3f2Aq/uTv3tdenBofutw8kMv1eFofb09Zie9UJ943PZtIjT50jNiWrPdneU9LqC6b9Ixq81E02l4i6bSD8JF755efLoMcHgLjQSmVZHhQS8g/qYozOIN9kuz5SicLv7riidMDySSWOqML5CAZaDy2m2sE7d+pVibmSs; 20:D/WF09Z/sR49fUyZXFqC169xyhNOlhNUT4EvRksDYKHKqvn09b0a+8v3GOCeJwio6nBzUxfEkTwVKCW6h3IGctxVz6cnCqvK1LuAupRqyNsXAJmpieAkwQ9xsg6tnWMo6/t5PUyHR3uHVWP/jrAyINh5mgWyeGhvrmECmNuJO9I=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 306f74e9-af54-412d-380e-08d55eac2737
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2190;
x-ms-traffictypediagnostic: SN6PR1501MB2190:
x-microsoft-antispam-prvs: <SN6PR1501MB2190D377D4F317938CA68F4DCDE80@SN6PR1501MB2190.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(85827821059158)(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040495)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231023)(11241501184)(2400066)(944501161)(6041282)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:SN6PR1501MB2190; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN6PR1501MB2190;
x-forefront-prvs: 05568D1FF7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(366004)(39860400002)(39380400002)(51444003)(189003)(199004)(7736002)(39060400002)(82746002)(478600001)(2950100002)(105586002)(229853002)(3660700001)(99286004)(106356001)(33656002)(4326008)(25786009)(5660300001)(14454004)(97736004)(6116002)(53546011)(2906002)(6486002)(316002)(6506007)(102836004)(110136005)(81166006)(3280700002)(6246003)(8676002)(54906003)(59450400001)(6436002)(305945005)(81156014)(5250100002)(2900100001)(6512007)(53936002)(36756003)(3480700004)(83716003)(86362001)(68736007)(8936002)(93886005)(76176011)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2190; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Rq8j1xaeYibepnGLoJbH0XbePdTOCssbmQh6B7VoAtaSMPSvU0PimepRA0/7hqokEYZ+rbnehP88jHvb9Yr/OQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <D586A87930195E44A38DC0B9E77FB00D@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 306f74e9-af54-412d-380e-08d55eac2737
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2018 19:46:22.6703 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2190
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-18_08:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/0DyVrYOeZWucI9kaZ-cHsc_LtSE>
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: Thu, 18 Jan 2018 19:46:52 -0000

I don’t believe that anything we specify in the protocol can solve the issue w.r.t. flow control and intermediaries (in  which the application framework itself might count as an intermediary).
At best we may mitigate the issue by offering a strategy that offers better outcomes than “try, timeout, retry.”

We have a concrete case here in compression. In particular, compression may be point-to-point and entirely within the domain of the protocol implementations, but flow-control is exerted end-to-end and beyond the domain of the protocol.
If compression/compression data is to be flow-controlled, then it is worth thinking about compression-specific mitigations which are better than ‘try, timeout, retry.’

-=R

On 1/17/18, 11:22 PM, "Martin Thomson" <martin.thomson@gmail.com>; wrote:

    Yes, what Ian said (and more to what Jana said).  I think that we've
    some proportion of the working group who are operating on one set of
    assumptions and another on a different set of assumptions on this
    subject.  Until now, that didn't bother me much.  After all, that's
    normal for a whole range of issues.
    
    Now there's a concrete problem, so let's dig into this properly.
    
    FWIW, I don't think that we'll resolve this particular issue in
    Melbourne, but I hope that we can at least start that process.  This
    promises to be interesting.
    
    On Thu, Jan 18, 2018 at 9:36 AM, Ian Swett <ianswett@google.com>; wrote:
    > +1 million
    >
    > On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar <jri@google.com>; wrote:
    >>
    >> We will discuss this at the interim, but one comment, inline.
    >>
    >>>
    >>> In part, it's the ignorance of the intermediary that causes this
    >>> particular problem.  If the intermediary was aware of the protocol
    >>> details then it might be able to recognize and avoid these situations,
    >>> but that seems a little too much to expect of intermediaries. Ruling
    >>> out the entire class of intermediary that operates purely at the
    >>> transport layer is extremely harsh.
    >>>
    >>> What is more likely here is that we describe this situation, explain
    >>> that it is impossible to prevent in the presence of intermediation,
    >>> and explain how to kill the right streams in order to ensure forward
    >>> progress doesn't stall indefinitely.
    >>
    >>
    >> Exactly because intermediaries make things difficult, it's important to be
    >> certain that the intermediary behavior we are discussing is one that there's
    >> a strong argument for supporting. We have spent countless cycles on
    >> designing around uncertain and unknown intermediary behaviors in various
    >> parts of the IETF, and I don't want us to recreate these boogeymen. I think
    >> it's reasonable to rule out classes of middleboxes if we don't have strong
    >> arguments for supporting them.
    >>
    >
    >