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

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 <rahul.ietf@gmail.com> 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
> 6lo-fragmentation-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo-fragmentation-dt