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

["Pascal Thubert (pthubert)" <[e-mail]>]

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,

Pascal

Le 19 sept. 2018 à 06:25, Rahul Jadhav <[e-mail]<mailto:[e-mail]>> 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.

Thanks,
Rahul

On Wed, 19 Sep 2018 at 01:29, Carsten Bormann <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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:
> 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
>
> _______________________________________________
> 6lo-fragmentation-dt mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/6lo-fragmentation-dt

_______________________________________________
6lo-fragmentation-dt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6lo-fragmentation-dt