IETF Logo Mail Archive

Re: [6lo-fragmentation-dt] Performance report for fragment forwarding

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 18 September 2018 17:13 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo-fragmentation-dt@ietfa.amsl.com
Delivered-To: 6lo-fragmentation-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87585130E5F for <6lo-fragmentation-dt@ietfa.amsl.com>; Tue, 18 Sep 2018 10:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1CgtTsKvL7Pw for <6lo-fragmentation-dt@ietfa.amsl.com>; Tue, 18 Sep 2018 10:13:55 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EF2127B92 for <6lo-fragmentation-dt@ietf.org>; Tue, 18 Sep 2018 10:13:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9334; q=dns/txt; s=iport; t=1537290835; x=1538500435; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dPy0r6UKGdeMdA3LS+Spby5RPjo+Vs9cbYGOx0Cy580=; b=QOboMDaqrQ+efLNXS/UtpincnEcIieih2+fIXGhrLfD+0G4Xtj5RNhaz y/DngWStmzglZFBWmqxSI4YMEKboDQGON4M4RvoDX2HmFMRBL7rCazX6r 3FV5i3IVMul4NKagbfzi99IrMcDMIfCyIRQdsC+09VwsT+qHV5O1sgDQ/ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AtAADQMaFb/5ldJa1bGQEBAQEBAQEBAQEBAQcBAQEBAYFSgQ93ZX8oCoNolESCDZERhTuBegslhEcCF4MPITYWAQMBAQIBAQJtHAyFOAEBAQQjCkwQAgEIEQQBASsCAgIwHQgCBAENBQiDGQGBHWQPpGqBLoQsBIVXBYptF4FBP4QkgSaBdQKBQQEBgx+CVwKNVY58CQKGQIlXH4FDhEyJBYtriFgCERSBJSQBMIFVcBWDJ4YBilJvin0NFweBAYEeAQE
X-IronPort-AV: E=Sophos;i="5.53,390,1531785600"; d="scan'208,217";a="443578731"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2018 17:13:54 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w8IHDs99004310 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Sep 2018 17:13:54 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Sep 2018 12:13:53 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Tue, 18 Sep 2018 12:13:53 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Rahul Jadhav <rahul.ietf@gmail.com>, "6lo-fragmentation-dt@ietf.org" <6lo-fragmentation-dt@ietf.org>
CC: "rabinarayans@huawei.com" <rabinarayans@huawei.com>, "yasuyuki.tanaka@inria.fr" <yasuyuki.tanaka@inria.fr>
Thread-Topic: [6lo-fragmentation-dt] Performance report for fragment forwarding
Thread-Index: AQHUT2lvdrEYlBd9b0+UYF3V1708sqT2Rc2g
Date: Tue, 18 Sep 2018 17:13:34 +0000
Deferred-Delivery: Tue, 18 Sep 2018 17:13:00 +0000
Message-ID: <3b706d46f1e64f46a6c290e26ab8be12@XCH-RCD-001.cisco.com>
References: <CAO0Djp2EKyiZK5-b+_R4c557mXSktPCEtYxOQjQb4vreTVOX9g@mail.gmail.com>
In-Reply-To: <CAO0Djp2EKyiZK5-b+_R4c557mXSktPCEtYxOQjQb4vreTVOX9g@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.106.207]
Content-Type: multipart/alternative; boundary="_000_3b706d46f1e64f46a6c290e26ab8be12XCHRCD001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo-fragmentation-dt/x9QiWCIxnIyEKmV7ePKcSODdSzI>
Subject: Re: [6lo-fragmentation-dt] Performance report for fragment forwarding
X-BeenThere: 6lo-fragmentation-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 6lo Fragmentation Design Team <6lo-fragmentation-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo-fragmentation-dt>, <mailto:6lo-fragmentation-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo-fragmentation-dt/>
List-Post: <mailto:6lo-fragmentation-dt@ietf.org>
List-Help: <mailto:6lo-fragmentation-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo-fragmentation-dt>, <mailto:6lo-fragmentation-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2018 17:13:58 -0000

Yes, I documented that issue when I presented to the 6lo WG. The only protection is to introduce delay between fragments so they get out of interference domain before you send the next one. The next problem is incast in the network, when you start multiple flows that cross/converge at a same intermediate node. My draft allows for flow control by asking an ack every so many fragment…
Take care,
Pascal

From: 6lo-fragmentation-dt <6lo-fragmentation-dt-bounces@ietf.org> On Behalf Of Rahul Jadhav
Sent: mardi 18 septembre 2018 18:05
To: 6lo-fragmentation-dt@ietf.org
Cc: rabinarayans@huawei.com; yasuyuki.tanaka@inria.fr
Subject: [6lo-fragmentation-dt] Performance report for fragment forwarding

<< turns out my earlier mail didn't reach the ML; trying again >>

Hello all,

We experimented with Fragment Forwarding and tried to understand the performance implications vis-a-vis per-hop reassembly.

Following is the detailed report:
https://github.com/nyrahul/ietf-data/blob/master/6lo-fragfwd-perf-report.md

To summarize, we found that fragment forwarding has some practical issues when it comes to forwarding efficiency or PDR "on single channel 802.15.4". While similar concerns were been raised previously during IETF meetings, we tried to validate it with data.

Please let us know if any comments.

Regards,
Rahul

v2.23.0 | Report a Bug | By Email