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

Rahul Jadhav <> Wed, 19 September 2018 04:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34BA5130E65 for <>; Tue, 18 Sep 2018 21:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bdv2QeaWwpzo for <>; Tue, 18 Sep 2018 21:25:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 826A3130F36 for <>; Tue, 18 Sep 2018 21:25:29 -0700 (PDT)
Received: by with SMTP id u11-v6so2019716uan.13 for <>; Tue, 18 Sep 2018 21:25:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k/YjILSdGKS/62FcWzjXZfb3Xmgb/n+OYE7M7mh/zF4=; b=GQgdq5QD1A1kPrh5oe8yzQNZRomI9cbQ2u3AQuoKVtut/ZVcp3lZzdyj24GZCzSj1w r8C8Oybgv9/WSntNX+hK5j5s91xtH0BxNmFE8MRyvyuaahJmd+P86aB2CAEj3hODnDFh utN3Juk8BmGr3GvvtUcl2DZfjuFvp/gRiDvq9Ft9TT4wEr26YdNcoNzYSPOypzXzqVz7 4s1QYaV8FO8ZNYCFl+a8+fbABhInI5vQ+XPVHMXRk/e+AawPuDcBRAMUCEpBp3/fVFL4 x3J4276u0l6/i9b3H5N+N1GhKpWJoqZfeVvuuZZR1pSP78s5+dZXW7C+jc3+FtIymmfC 9CRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k/YjILSdGKS/62FcWzjXZfb3Xmgb/n+OYE7M7mh/zF4=; b=FFKObG651smT3NVzkFPmEiOStpAkU8+iA2EauBtGSyUCS5+6U0F7ptFU6y/7OxRzHL RSJRM17EaE4simgUDSFf0044XCWyaGwgEJ9xuizNM/dE81I9uU/6klSS4gBbhTXPCI30 nthtsfvdKNHrInhPW/AJetqn9A9MAL+XysFCAxsaLu8gnJGHz1U3ZUk23xgsky4h2Cok BKEcsmzNX4bLq/eWueNb+DOMGjWSQbTZhwsQKqw7fPZLr/bbrwxIE+7iXO0k7EFG68sZ lXx/3fnpq1lvwBKFgv4itvQxJPRwhNdJYPQm5uy9UVAutenpydmGnDQFQeEIP/+XsBBk w+Yw==
X-Gm-Message-State: APzg51DpHiTrm39F1jBGz7+6xEsaJ3FSm1V2o1uk6D72uqprFmXdIc5k K4tQI0xVm4wIPnmpvr40uf9B6G57qWuAti7H0E0=
X-Google-Smtp-Source: ANB0Vda3Mi+hhRcYXwf2FlPVBOITIVm2S68/ozB4xD1z5R/FDoNImwiLRvzsbnKgncE6k3fW4jy7d2E5f0KDbay6xKk=
X-Received: by 2002:a9f:2b87:: with SMTP id y7-v6mr9667121uai.109.1537331128455; Tue, 18 Sep 2018 21:25:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Rahul Jadhav <>
Date: Wed, 19 Sep 2018 09:55:16 +0530
Message-ID: <>
To: Carsten Bormann <>
Content-Type: multipart/alternative; boundary="000000000000d054ae057631cb6b"
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 04:25:32 -0000

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
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
> >
> >