Return-Path: X-Original-To: lwip@ietfa.amsl.com Delivered-To: lwip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33C8131225; Tue, 9 Oct 2018 02:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.972 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sQv8Hwus39XJ; Tue, 9 Oct 2018 02:20:16 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BC71311AA; Tue, 9 Oct 2018 02:20:15 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id a202so806845vsd.5; Tue, 09 Oct 2018 02:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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, 9 Oct 2018 14:50:02 +0530 Message-ID: To: samita.chakrabarti@verizon.com Cc: lo <6lo@ietf.org>, lwip@ietf.org Content-Type: multipart/alternative; boundary="000000000000d0d20e0577c83ef0" Archived-At: Subject: Re: [Lwip] [E] [6lo] fragment forwarding implementation and performance report X-BeenThere: lwip@ietf.org 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 --000000000000d0d20e0577c83ef0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Samita for the feedback. Please find my response inline. Regards, Rahul > From the results, I noticed an observation that send rate 80s, and 40s ar= e > doing better than the 160s send rate with 50s forwarding fragment spacin= g. > 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 i= s > 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 si= ze > 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: > >> >> >> >> >> 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: >> >> https://github.com/nyrahul/ietf-data/blob/rst/6lo-fragfwd-perf-report.rs= t >> >> >> >> >> 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 >> 6lo@ietf.org >> >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_6lo&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ= &r=3DpWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=3DPeFHI-ltr748QRhWwqigY8= iNFPw9EcyFDwOeSrv6KQc&s=3DebzWBVEJyovVUcFHM2mByigGnDBv0aoTSm21fmwa5vU&e=3D >> > --000000000000d0d20e0577c83ef0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Samita for the feedback.
Please find my resp= onse inline.

Regards,
Rahul

<= div dir=3D"ltr">
=
From the results, I noticed an observati= on that send rate 80s, and 40s are doing better than the 160s=C2=A0 send ra= te with 50s forwarding fragment spacing. Send rate Xs means sending fragmen= ted packets at X sec interval - right?

The payload size before fragmentation is different fo= r 40s, 80s, 160s, which is 256B, 512B and 1024B respectively. So at 160s th= e payload size is 1024B which will result in more fragments per payload. Th= us 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 t= hen 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) befo= re every fragment is sent on the original sender.=C2=A0
=C2= =A0
I thought, the performance would improve with higher X valu= e,=C2=A0 but that is not true - perhaps due to increased payload size.

Yes, the increased pa= yload size causes higher number of fragments per payload which increases pa= yload loss probability since a single fragment loss will cause complete pay= load failure.
=C2=A0
A graph or tabular result with s= ame payload size with increased send interval rate might be useful to figur= e out the optimal pacing time for that payload - just a thought.=C2=A0

Yes this can be attem= pted. But as of current observations it seems that unless you have smart pa= cing algorithm the use of fragment forwarding can backfire considering that= under the same conditions the per hop reassembly works much better. We tri= ed pacing with 50ms and 100ms delay ... with 100ms the PDR of fragment forw= arding is almost same as per hop reassembly but with much higher end to end= latency.
=C2=A0

In general, very interesting results!

Also, it shows that by controlli= ng the pacing of forwarding the fragments the performance can be improved t= o a great degree in a medium to small size mesh. ( in this example, 50 node= s).

What happens when you increase the mesh size ( aka number of nodes)?

Yes we can increase t= he mesh size but then i do not think it will change the inferrences much. W= e also wanted to try different (higher) node densities which i feel might f= urther cause problems for fragment forwarding. Among other things we also w= ant to experiment with fragment acknowledgement mechanism. But we havent re= ally validated all these points.
=C2=A0

Cheers,
-Samita=

On Mon,= Oct 8, 2018 at 7:17 AM Rahul Jadhav <rahul.ietf@gmail.com> wrote:

<sending to 6lo, lwig WGs because both have relevant drafts>=

=C2=A0

Hello All,


<= p class=3D"MsoNormal">We tried experimenting with the virtual reasse= mbly buffer and fragment forwarding drafts.

One f= undamental characteristic that has major implications on fragment forwardin= g performance is its behavior with realistic 802.15.4 RF (especially when a= train of fragments are simultaneously received and transmitted). This is s= omething which was not evaluated in any other experiment.

=C2=A0

You ll find = the details of the implementation, test setup details and performance resul= t here:

https://git= hub.com/nyrahul/ietf-data/blob/rst/6lo-fragfwd-perf-report.rst

=C2=A0

Results are quite interesting: Simultaneous send/recv of fragments with= fragment forwarding has major implications on PDR/Latency.

=C2=A0

Feedback most welcome.

= =C2=A0

Thanks,

Rahul

_______________________________________________
6lo mailing list
6lo@ietf.org
http= s://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_lis= tinfo_6lo&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBT= Q&r=3DpWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=3DPeFHI-ltr748Q= RhWwqigY8iNFPw9EcyFDwOeSrv6KQc&s=3DebzWBVEJyovVUcFHM2mByigGnDBv0aoTSm21= fmwa5vU&e=3D
--000000000000d0d20e0577c83ef0--