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

[sajjad akbar <[e-mail]>]

Possibly you could find in NS3 as per my information its not available in
Castalia. But I agree it will generate huge overheads for a single channel.

Rahul, could you suggest that the same mechanism could be used for IEEE
802.15.6 as per our draft
https://datatracker.ietf.org/doc/draft-sajjad-6lo-wban/?  It will be good
to adopt a similar mechanism. We are trying to finalize our draft and
possibly I will upload a revised version next week. Tell me your thougts on
it.

Regards
Sajjad


On Tue, Oct 9, 2018 at 10:14 PM Rahul Jadhav <[e-mail]> wrote:

> We havent tried RTS/CTS .. i thought 802.15.4 does not support RTS/CTS
> because of high overhead.
> Anyways i tried checking if ns3 (which is what we use in backend) supports
> it and i could not find any support.
> I checked Castalia and that too does not seem to support RTS/CTS.
>
> Having said that, ns3 does implement carrier sensing which is also what we
> use.
>
> Best,
> Rahul
>
>
> On Tue, 9 Oct 2018 at 16:21, sajjad akbar <[e-mail]> wrote:
>
>> Hi Rahul,
>>
>> That's an interesting solution and useful as you packet delivery is
>> improved. Other than pacing, did you try RTS/CTS as usually simulators have
>> this option for IEEE 802.15.4 based node for channel access/attempt? I am
>> not sure either it create more delay for your case.
>>
>> Regards
>> Sajjad
>>
>> On Mon, Oct 8, 2018 at 11:27 PM Rahul Jadhav <[e-mail]>
>> wrote:
>>
>>> Hello Sajjad,
>>>
>>> The packet loss rates due to channel  were "relatively" same
>>> with/without fragment forwarding. The channel attempt rate was the primary
>>> problem. To verify this Carsten/Pascal suggested to try pacing with
>>> fragment forwarding.  After we tried pacing at the sender side, it resulted
>>> in much improved packet delivery, which also signals that channel attempt
>>> was the primary problem. Please note we used 802.15.4 in single channel
>>> CSMA/CA mode.
>>>
>>> Regards,
>>> Rahul
>>>
>>> On Mon, 8 Oct 2018 at 17:00, sajjad akbar <[e-mail]> wrote:
>>>
>>>> Hello Rahul,
>>>>
>>>> Looks interesting. Could you elaborate the reason of failure? is it
>>>> only due to channel attempt? Did you observe packet loss? I did not get
>>>> chance to read your previous discussions, may be you already discussed this.
>>>>
>>>> Regards
>>>> Sajjad
>>>>
>>>> On Mon, Oct 8, 2018 at 10:17 PM 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
>>>>>
>>>>>
>>>>>
>>>>> 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://www.ietf.org/mailman/listinfo/6lo
>>>>>
>>>>