Re: [Lwip] [E] [6lo] fragment forwarding implementation and performance report

Rahul Jadhav <> Tue, 09 October 2018 09:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A33C8131225; Tue, 9 Oct 2018 02:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.972
X-Spam-Status: No, score=0.972 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sQv8Hwus39XJ; Tue, 9 Oct 2018 02:20:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1BC71311AA; Tue, 9 Oct 2018 02:20:15 -0700 (PDT)
Received: by with SMTP id a202so806845vsd.5; Tue, 09 Oct 2018 02:20:15 -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=jdncqGw8p9UNfG9JGtyEvIJcbN6xaednjDq67vKfJYg=; b=E+gy4Wd7twqZsV148MdvetrtK4Qg8DPs7yZ3nphkpiCy8fjcClXRaPvgVsfKGelfUV cCVRhfXLzd6M7KJ9pGnNUtsilKeJfgk2PnlACOky+jcYENF+I2OVw/TrJuo+PKVZWoUb VSCa8QwHt2lJEpjZ/DkUE0J47XCSHN/9KnF/xmy8jmFEDxjj2SrPb/XWunhHKz7r4rLr pT4VLpUsRQjJ9FuNA4K8YEgH3tF9k/4a0n4lYx+kTK2vy7rJp5oq9BYPNWvPuCitgUhI AURAwzptvOYIVRF5wd2KSAUiiTK2J1rjeDza92uGLaXE71BWpRziuMLEW/TAQONM++xC XIxQ==
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=jdncqGw8p9UNfG9JGtyEvIJcbN6xaednjDq67vKfJYg=; b=f4poiPpVFr2n/cdwamav9sKHww7R8IYICqygBABhnApn9tjklHHO1M1v4PB5xQy06p twu2Z+wKPTxpFF2P/NNdvLInCExVEGiI8IZ6WpkYA/thMwkZ6DmSznbO1z9PUYiRi3wA C4NwH8zqsBvSOaERd78qQEAZ8OspTnYa5NC/DwZjhcLYGjA2duaw3sNSAV7C4yUQ2eD2 syVnwXVR/Nu773LeJqNyaB28XviDIYAe0rfRzyFnLpAD4NAEYkyRKJY+CRRjRlIbVMVz p24k+BqsSE+csjTX6qzs/4dLpydhf9OQ4oU0dN4e8vVYwAkFn2C4JjoYJaGkpw/9fx1T crjA==
X-Gm-Message-State: ABuFfoh4mIdETWilVAoW/vZQF5V8fW7ClWENCjsecYSTby6Ebeb1/mm6 gWximrvdHbMF69EBWHR0VR7n66NqVgiDE/3brOs=
X-Google-Smtp-Source: ACcGV60I0F/aPLQS3rPo/6/imih42N47KBNNNLR+5axyODWRUkJi1dgLRGrGtOuP3+WgvrHeF7jS+FQj1ocRAZk5gGo=
X-Received: by 2002:a9f:35f1:: with SMTP id u46-v6mr10871594uad.20.1539076814588; Tue, 09 Oct 2018 02:20:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Rahul Jadhav <>
Date: Tue, 09 Oct 2018 14:50:02 +0530
Message-ID: <>
Cc: lo <>,
Content-Type: multipart/alternative; boundary="000000000000d0d20e0577c83ef0"
Archived-At: <>
Subject: Re: [Lwip] [E] [6lo] fragment forwarding implementation and performance report
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Oct 2018 09:20:18 -0000

Thank you Samita for the feedback.
Please find my response inline.


> From the results, I noticed an observation that send rate 80s, and 40s are
> doing better than the 160s  send rate with 50s forwarding fragment spacing.
> Send rate Xs means sending fragmented packets at X sec interval - right?

The payload size before fragmentation is different for 40s, 80s, 160s,
which is 256B, 512B and 1024B respectively. So at 160s the payload size is
1024B which will result in more fragments per payload. Thus any loss of a
single fragment increases the failure rate of the complete payload.
There is no 50s fragment forwarding spacing .. There is __50ms & 100ms__
inter fragment spacing in case of fragment forwarding that was introduced
on the original sender (not forwarders).

The send logic is, we wait for 40s/80s/160s time duration and then randomly
choose a timer within 1-10s to start sending the UDP payload. After that in
case of fragment forwarding, we wait 50ms (pacing delay) before every
fragment is sent on the original sender.

> I thought, the performance would improve with higher X value,  but that is
> not true - perhaps due to increased payload size.

Yes, the increased payload size causes higher number of fragments per
payload which increases payload loss probability since a single fragment
loss will cause complete payload failure.

> A graph or tabular result with same payload size with increased send
> interval rate might be useful to figure out the optimal pacing time for
> that payload - just a thought.

Yes this can be attempted. But as of current observations it seems that
unless you have smart pacing algorithm the use of fragment forwarding can
backfire considering that under the same conditions the per hop reassembly
works much better. We tried pacing with 50ms and 100ms delay ... with 100ms
the PDR of fragment forwarding is almost same as per hop reassembly but
with much higher end to end latency.

> In general, very interesting results!
> Also, it shows that by controlling the pacing of forwarding the fragments
> the performance can be improved to a great degree in a medium to small size
> mesh. ( in this example, 50 nodes).
> What happens when you increase the mesh size ( aka number of nodes)?

Yes we can increase the mesh size but then i do not think it will change
the inferrences much. We also wanted to try different (higher) node
densities which i feel might further cause problems for fragment
forwarding. Among other things we also want to experiment with fragment
acknowledgement mechanism. But we havent really validated all these points.

> Cheers,
> -Samita
> On Mon, Oct 8, 2018 at 7:17 AM Rahul Jadhav <> wrote:
>> <sending to 6lo, lwig WGs because both have relevant drafts>
>> Hello All,
>> We tried experimenting with the virtual reassembly buffer and fragment
>> forwarding drafts.
>> One fundamental characteristic that has major implications on fragment
>> forwarding performance is its behavior with realistic 802.15.4 RF
>> (especially when a train of fragments are simultaneously received and
>> transmitted). This is something which was not evaluated in any other
>> experiment.
>> You ll find the details of the implementation, test setup details and
>> performance result here:
>> <>
>> Results are quite interesting: Simultaneous send/recv of fragments with
>> fragment forwarding has major implications on PDR/Latency.
>> Feedback most welcome.
>> Thanks,
>> Rahul
>> _______________________________________________
>> 6lo mailing list