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

[Carsten Bormann <[e-mail]>]

Hi Rahul,

> 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.

Pacing is something the origin of the datagram does; I wasn’t suggesting the forwarders to add that (which indeed essentially puts the datagram into buffers there).
Clearly, pacing is counterproductive when forwarders do full reassembly, as it increases the time the partially assembled datagram is vulnerable to fragments of other datagrams hijacking the buffer — you want to capture the channel as much as possible then (to the level that you’d want to send following fragments with a higher MAC priority).  Of course, as the datagram travels through the network, it will become more and more smeared over time.

It would be interesting to see how your numbers change with some pacing at the origin; it should be easy to hack that in if you are not trying to do this in a general way.

> 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 ?

Yeah, yet another tunable that in a robust protocol really should be self-tuning.
A MAC-layer retransmission is not useful if the layers above have already timed out.
So the latency introduced by the backoff mechanism is really the determining factor here.

Grüße, Carsten