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

"Pascal Thubert (pthubert)" <> Wed, 19 September 2018 05:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43310130F65 for <>; Tue, 18 Sep 2018 22:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Status: No, score=-14.509 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_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0PxgTFgxD4PG for <>; Tue, 18 Sep 2018 22:38:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CE72130DEF for <>; Tue, 18 Sep 2018 22:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13394; q=dns/txt; s=iport; t=1537335521; x=1538545121; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uJIpyCln0UaE9d6RSwHLaCmTN88Ql/hI0qxJefPC1RU=; b=KyjkXALBj+5OVjJveuUVh9hvPT9vdkSuyTLRF4wKLiWUsS56poMtkyGi pdG3DzHNbUZTmVsshEVhEAC11fRHwSob617E0UQR+/d6QE32N5w8gcHfs Bb+MB64Z5OJDExBa2QfX1VZEYYJMgoT+ahtpPujbL49BE5p/WwHBLUlNf k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAACm4KFb/4YNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFQgghlfyiDc4gVjDKCDYheiDOFO4F6CxgBDIRHAheDEiE?= =?us-ascii?q?0GAEDAQECAQECbRwMhTgBAQEBAgEBASFLCwULAgEGAhgnAwICAh8GCxQRAgQ?= =?us-ascii?q?OBYMhAYEdTAMNCA+IMZtMgS6ELASDBQ2CSgWKbReBQT+BOR+CTIEmgTBFAQG?= =?us-ascii?q?BQQEBgx8xgiYCjVeOUywJAoZAhkmDFxeBQ4ROiQeLbm2HbAIRFIElHTiBVXA?= =?us-ascii?q?VOyoBgkGGAYUUhT5viw8NFweCHwEB?=
X-IronPort-AV: E=Sophos;i="5.53,392,1531785600"; d="scan'208,217";a="457397920"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2018 05:38:20 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w8J5cKTX008220 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Sep 2018 05:38:20 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 19 Sep 2018 00:38:20 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Wed, 19 Sep 2018 00:38:20 -0500
From: "Pascal Thubert (pthubert)" <>
To: Rahul Jadhav <>
CC: Carsten Bormann <>, "" <>, "" <>, "" <>
Thread-Topic: [6lo-fragmentation-dt] Performance report for fragment forwarding
Thread-Index: AQHUT2lvdrEYlBd9b0+UYF3V1708sqT2yRmAgACNbQCAABRoAA==
Date: Wed, 19 Sep 2018 05:38:19 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_B340B396A1C049D6BCBFA8C04D98F8C9ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [6lo-fragmentation-dt] Performance report for fragment forwarding
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 6lo Fragmentation Design Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Sep 2018 05:38:44 -0000

Hello Rahul

Pacing is another word for introducing delay between fragments and yes thus locks the buffers for a longer time. Having to do retries because a fragment interferes with the next also introduces delay, and possibly longer if you keep at it.

The key message in my talk was that this problem simply goes away with 6TiSCH. I think that should be the key message of your writing...

Take care,


Le 19 sept. 2018 à 06:25, Rahul Jadhav <<>> a écrit :

Thanks Pascal, Carsten for the comments.

Pascal, Introducing delay is easy but it has further complications with regards to buffering requirement. Holding the fragment with a delay while receiving more fragments from the downstream would mean keeping additional buffers.
Carsten also mentioned a pacing mechanism .. while it might improve fwding efficiency it will add to buffer requirement. Also such a scheme might be non-trivial to be implemented.

Also Carsten, the PDR we reported takes into consideration all factors,, buffering as well (we use contiki and have single 1280B buffer on each node). While the transmission scheme we chose results in much less impact on buffering, it is much closer to our traffic pattern expectation.

Regarding keeping higher mac-retry, ... We have chosen mac-retry of 3 after some experimentation (considering expected node densities and tx frequency). increasing mac-retry might not necessarily help, in fact it may backfire in terms of both PDR as well as mean latency. Would you still suggest to give it a try and what mac-retry do you think makes sense ?

Based on your comment, we will document the fragments dropped on nodes in both scenarios, just to be clear.


On Wed, 19 Sep 2018 at 01:29, Carsten Bormann <<>> wrote:
Hi Rahul,

the memory issues in forwarders discussed during IETF101 are real, and they would need to enter the calculations about PDR differences.

Is a max-retry of 3 something that people are actually choosing? Sounds low to me.

More importantly, it seems we neglected to discuss pacing in both draft-watteyne-6lo-minimal-fragment-02.txt and draft-ietf-lwig-6lowpan-virtual-reassembly-00.txt.  Pacing is essential for fragment forwarding (as it is for any application that sends more than one datagram in a row).  If the original sender does not pace, there will always be a collision between the forwarding of fragment N and the origination of fragment N+1.

Unfortunately, pacing is another knob that needs to be tuned, and I’m not aware of good research that tells us what  the right setting for that knob is.  Ideally, we’d want it to be self-tuning.

Grüße, Carsten

> On 18. Sep 2018, at 18:05, Rahul Jadhav <<>> wrote:
> << 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:
> 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
> _______________________________________________
> 6lo-fragmentation-dt mailing list

6lo-fragmentation-dt mailing list<>