Hi Pascal,Thanks for the explanation on the following points.
On Tue, Oct 9, 2018 at 7:48 AM Pascal Thubert (pthubert) <[email protected]> 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* > > >
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
