Re: [dtn] [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
"Zhouxingwang (Joe)" <zhouxingwang@huawei.com> Mon, 06 January 2020 08:47 UTC
Return-Path: <zhouxingwang@huawei.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7021200B3; Mon, 6 Jan 2020 00:47:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ohYstDNVA5pC; Mon, 6 Jan 2020 00:47:21 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 8120C12001E; Mon, 6 Jan 2020 00:47:21 -0800 (PST)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 21A39AEEE36543686AC9; Mon, 6 Jan 2020 08:47:20 +0000 (GMT)
Received: from dggeme755-chm.china.huawei.com (10.3.19.101) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 6 Jan 2020 08:47:19 +0000
Received: from dggeme758-chm.china.huawei.com (10.3.19.104) by dggeme755-chm.china.huawei.com (10.3.19.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 6 Jan 2020 16:47:17 +0800
Received: from dggeme758-chm.china.huawei.com ([10.6.80.69]) by dggeme758-chm.china.huawei.com ([10.6.80.69]) with mapi id 15.01.1713.004; Mon, 6 Jan 2020 16:47:17 +0800
From: "Zhouxingwang (Joe)" <zhouxingwang@huawei.com>
To: Stuart William Card <stu.card@critical.com>, Carsten Bormann <cabo@tzi.org>
CC: "nwcrg@irtf.org" <nwcrg@irtf.org>, "loops@ietf.org" <loops@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
Thread-Index: AQHVxA5wn08ZkzTEl06o0CselVnRRafcV/gAgAD4cVA=
Date: Mon, 06 Jan 2020 08:47:17 +0000
Message-ID: <abe6495a7d6e4b89bea3c48bd62c0c50@huawei.com>
References: <AAF1E19E-37C1-4A9D-B92A-621054B06AF6@tzi.org> <c172b80c-04ee-9786-153f-9e1dda57fdd8@steinwurf.com> <3D026CEF-AF7D-4CDE-8A5B-8CE5DCF749D1@tzi.org> <163A8040-9B13-43AA-8917-F75D984B0EBF@tzi.org> <26708398-5DEB-478E-8CB8-D406A8B874FF@tzi.org> <7DC0B005-8BA2-4D80-8CDF-4E2AE7EA96F3@tzi.org> <24526f0dbdcbdb65951d16cb5770fcbe.squirrel@www.critical.com> <A5F38E44-F83A-41EC-AFF6-90EDFFFDF057@tzi.org> <266cb00cb46ed971f3055a086b421312.squirrel@www.critical.com>
In-Reply-To: <266cb00cb46ed971f3055a086b421312.squirrel@www.critical.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.27.230]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/hrR8ZlYhsPymvNDW-KBy5g8anac>
Subject: Re: [dtn] [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2020 08:47:25 -0000
Hi, It seems Linux TCP is much more out-of-order tolerant than we think. 1) TCP can dynamically adjust flow reordering level, not stick to 3. (https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) tcp_reordering - INTEGER Initial reordering level of packets in a TCP stream. TCP stack can then dynamically adjust flow reordering level between this initial value and tcp_max_reordering Default: 3 tcp_max_reordering - INTEGER Maximal reordering level of packets in a TCP stream. 300 is a fairly conservative value, but you might increase it if paths are using per packet load balancing (like bonding rr mode) Default: 300 2) RACK has been enabled by default in Linux for loss detection since kernel4.4. (https://kernelnewbies.org/Linux_4.4) tcp_recovery - INTEGER This value is a bitmap to enable various experimental loss recovery features. RACK: 0x1 enables the RACK loss detection for fast detection of lost retransmissions and tail drops. It also subsumes and disables RFC6675 recovery for SACK connections. RACK: 0x2 makes RACK's reordering window static (min_rtt/4). RACK: 0x4 disables RACK's DUPACK threshold heuristic Default: 0x1 The retransmission conflict between TCP and other layer will not be a big issue. Thanks Joe -----Original Message----- From: nwcrg [mailto:nwcrg-bounces@irtf.org] On Behalf Of Stuart William Card Sent: Monday, January 06, 2020 9:46 AM To: Carsten Bormann <cabo@tzi.org> Cc: nwcrg@irtf.org; loops@ietf.org; dtn@ietf.org Subject: Re: [nwcrg] [LOOPS] IETF106: LOOPS side meeting on Tuesday 08:30, Orchard Room Carsten -- Thanks for your thoughtful response. I'll try to focus my inputs. :-) > ... > (1) ... more intricate (and timely) knowledge of the critical path segment... > (2) techniques such as TCP splitting allowed mitigating some... > of the latency induced performance issues end-to-end protocols exhibited... > With increasing use of encryption... (2) is going away... > (1) will stay relevant... where that knowledge can be provided... > What LOOPS is trying to do is providing a protocol that can help even > in the absence of both (1) and (2)... > recovering packets can lead to reordering... > applications will need to be part of the picture... > LOOPS itself will need to focus on a more narrow set of problems and > opportunities, and this is the time to discuss whether we got that > narrowing right in the current charter proposal... Agreed. Further, not only transport but also network layer encryption kills simple approaches to (2), leaving AFAIK only multipath or trading increased mean latency to reduce latency variance. Many of us have suffered from suboptimal and sometimes unanticipated interactions between link and transport layer behaviors (retransmission in both, flow control in the data link, congestion control in the transport). Application layer adaptive behaviors (e.g. video streaming that switches dynamically during a session among different source coding rates based upon end to end performance as it varies) further complicate this. LOOPS will be yet another interacting control loop. In the worst case, a non-congestion loss of a link layer frame could lead to: - data link retransmission - LOOPS retransmission - transport retransmission - transport backoff - application rate downshift All at once! Presumably we can't prevent this altogether but want to minimize its occurrence. The charter looks good. I suggest broadening its scope of consideration of cross-layer interactions: not just w/transport congestion control, but also w/retransmission, misordering & resequencing at all layers. -- Stuart W. Card, VP & Chief Scientist Critical Technologies Inc. (CTI) <stu.card@critical.com> _______________________________________________ nwcrg mailing list nwcrg@irtf.org https://www.irtf.org/mailman/listinfo/nwcrg
- Re: [dtn] [nwcrg] [LOOPS] IETF106: LOOPS side mee… Stuart William Card
- Re: [dtn] [LOOPS] [nwcrg] IETF106: LOOPS side mee… Carsten Bormann
- Re: [dtn] [nwcrg] [LOOPS] IETF106: LOOPS side mee… Stuart William Card
- Re: [dtn] [nwcrg] [LOOPS] IETF106: LOOPS side mee… Zhouxingwang (Joe)