Re: [Lwip] [E] [6lo] fragment forwarding implementation and performance report

[Rahul Jadhav <[e-mail]>]

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 are
> doing better than the 160s  send rate with 50s forwarding fragment spacing.
> 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 is
> 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 size
> 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 <[e-mail]> wrote:
>
>> <sending to 6lo, lwig WGs because both have relevant drafts>
>>
>>
>>
>> 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.rst
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nyrahul_ietf-2Ddata_blob_rst_6lo-2Dfragfwd-2Dperf-2Dreport.rst&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=PeFHI-ltr748QRhWwqigY8iNFPw9EcyFDwOeSrv6KQc&s=Rtytc7AFwMLDcwFQOSojZZZ3hiXl-j78GKTwYRi8Nw0&e=>
>>
>>
>>
>> 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
>> [e-mail]
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_6lo&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=PeFHI-ltr748QRhWwqigY8iNFPw9EcyFDwOeSrv6KQc&s=ebzWBVEJyovVUcFHM2mByigGnDBv0aoTSm21fmwa5vU&e=
>>
>