On Nov 5, 2012, at 13:56, "Cao Zhen (cz)" <[email protected]> wrote:
> Hi Carsten, > > The problem you describe is cool. But in Lwig guidance document, I > remember there is a guidance saying we should avoid fragmentation if > we can. Yes, but how do you do that if you don't know the fragment size? Right now, you can only guess, and you'll likely try to guess conservatively, missing out on the opportunity to reasonably fill the packets. > And also applications are also diet in 6lowpan, so I am not > sure the case we envision fragment problem. Indeed, simple sensor readings/actuator settings are unlikely to trigger fragmentation. Unfortunately, when the need for bulk data arises (firmware updates, configuration changes), it often is needed for many nodes in the network, which means the speed at which you can perform these operations at scale depends on the efficiency you can get. > The fact is that in Internet today only has very very few fragments, > due to the fact of MTU configuration/discovery and also TCP MSS > option. Yes. We have ways to find out the IP MTU and therefore mostly can avoid fragmentation if our protocols are set up for that. My problem statement is that we can't do that at the adaptation layer. We simply didn't provide a way to find out the fragment sizes for the adaptation layer. > I think I am not the only lucky guy to have not witnessed any fragments:) Lucky you :-) Please have a look into the 6lowpan packet repository at http://svn.tools.ietf.org/svn/wg/6lowpan/packets/ if you want to see 6LoWPAN fragmentation in action... Grüße, Carsten _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
