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

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

Hi Pascal,Thanks for the explanation on the following points.


On Tue, Oct 9, 2018 at 7:48 AM Pascal Thubert (pthubert) <[e-mail]>
wrote:

> Hello Rahul and Samita :
>
>
>
> 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.
>
>
>
> *[PT>] Yep: this shows the chances of not only losing the packet but
> buffer bloat on the receiver, which entails not having memory left for
> receiving normal packets. IOW this justifies doing recoverable fragments.*
>
>
>


It would be great to try out the intelligent fragment-forwarding draft
(Pascal's draft) on the same setup and show the difference in efficiency.

Just curious, in your estimate, does the forwarding issue show up more on
6tisch network compared to other technologies that don't have such reliable
L2?
This is something to think about for implementation recommendations-- for
example, intelligent fragment forwarding will be needed for efficient use
6tish network with payload range X and Y.
Similarly, if other technologies mostly use small payloads and can
reasonably work well with implementing minimal fragment forwarding, then
documenting that information will be very useful for deployment.

Thanks,
-Samita


>
>
> 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 inferences 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 haven’t really validated all these points.
>
> *[PT>] In a real network we can expect more than one flow. Here the one
> packet appears smooth but that’s because there is nothing to interfere
> with. What if you kept on sending packets continuously, and over multiple
> crossing paths?*
>
> *There are really 2 effects that justify pacing the fragments. With a
> channel hopping technology like TSCH, it is just to left the next hop
> forward the fragment, so the wait can be short. When using a single
> frequency, there is also avoidance of hidden terminal between consecutive
> fragments, which means that we have to wait for the fragments to relay over
> multiple hops.*
>
> *This tells us that the fragment forwarding technique is a lot more
> efficient when coupled with 6TiSCH. None of this is a surprised, all was
> described to the group when we started (see my slides from a few IETFS ago,
> see slide 32 of
> https://datatracker.ietf.org/meeting/101/materials/slides-101-6lo-fragmentation-design-team-formation-update-00
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_101_materials_slides-2D101-2D6lo-2Dfragmentation-2Ddesign-2Dteam-2Dformation-2Dupdate-2D00&d=DwMGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=nVLkPPTF9g3I6X86AD76uwafjmV4U0IYkfZ0N8AQ25g&s=pTBiqO4WbYobDfj04cufLA9ev4-9M6XqKX-6pPxCCSQ&e=>
> ).*
>
>
>
> *I hope others continue the great work that Rahul has started, in
> particular with TSCH and multiple flows.*
>
>
>
> *Take care,*
>
>
>
> *Pascal*
>
>
>