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

[Rahul Jadhav <[e-mail]>]

Agreed. 6TiSCH with nodes using non-shared cells for transmission will be
the best deployment scenario for fragment-forwarding.
Unfortunately our testbest currently does not support TSCH and thus we wont
be able to report the numbers.

On Wed, 19 Sep 2018 at 11:08, Pascal Thubert (pthubert) <[e-mail]>
wrote:

> 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]> 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]> 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]> 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]
>> > https://www.ietf.org/mailman/listinfo/6lo-fragmentation-dt
>>
>> _______________________________________________
> 6lo-fragmentation-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo-fragmentation-dt
>
>