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

["Chakrabarti, Samita" <[e-mail]>]

Hi Rahul,

Thanks for the clarification points.  If convenient, an analysis of optimum
payload recommendation for minimal fragment forwarding draft will be great!
In that case, the draft can recommend  that value or at least throw the
information in the appendix section for a guidance.

Great work! We  should do more such collaboration with lwip wg!

Cheers,
-Samita

On Tue, Oct 9, 2018 at 5:20 AM Rahul Jadhav <[e-mail]> wrote:

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