Re: [Contiki-developers] 6LoWPAN fragmentation and reassembly

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi   Tommaso,

I am new to WSN , so excuse my ignorance. But, wouldn't it be safe to
assume fragmented 6LoWPAN transmission is a rarity in a typical WSN? Even
the control packet's size, I assume remains low to fit in a 6LoWPAN
fragment.

Regards,
Tom

On Sat, Jan 14, 2012 at 6:55 AM, Tommaso Pecorella <tpe...@me...>wrote:

> Hi Colin,
>
> thanks for your answer.
>
> Yeah, it's route over, but you understood what I meant :) I was referring
> to a slightly more complex case tho.
>
> If you check the Zack Shelby's book (not the Bible, but a good source for
> sure), you'll find that multihop can be done actually in 3 points:
> - L2: mesh-under. Invisible to 6LoWPAN and above layers
> - L3: route-over. The packet needs to be reassembled or you'll need *very*
> dirty tricks. Not the sort of tricks you wanna do in a low power device.
> - L2.5; inside 6LoWPAN, accessing directly the IP routing tables. I don't
> know how to call this one. Forwarding-inside ?
>
> Now, I do agree that it's all a design choice, and that supporting all the
> 2 modes in 6LoWPAN (mesh-under is invisible to 6LoW so I don't consider it
> in this discussion) would make the code quite complex. On the other hand I
> was interested into the rationale of the choice, and if it was discussed at
> some point.
>
> The pros of reassembling are for sure that you can spot the "problem" (if
> there is) in a link, the cons are that 1) you'll have to consume memory for
> reassembly and 2) there is an increased packet processing delay in the
> node, since before forwarding, a node will have to receive the whole set of
> fragments.
> Now, the delay is not usually a problem, but the memory can be.
>
> Comparing Contiki to TinyOS implementations (both do reassembly inside the
> forwarding nodes), I've noticed that Contiki uses just one buffer, thus if
> a node will have to forward two fragmented packets at the same time they
> might be both lost. This might happen in a poorly designed data collection
> system, where the sensors are sending fragmented packets toward the DODAG
> root.
>
> TinyOS do have multiple buffers, but they're still a fixed and limited
> number, so the problem is not eliminated, it's just less noticeable. It
> might still trigger and due to Murphy's law it will, as soon as your
> sensors network is deployed.
>
> Direct fragment forwarding have the pro to not require any memory, but the
> following cons:
> 1) you have to rely on a cross-layer information, and this is usually a
> nightmare. You need to assume that there is µIP, that the routing tables
> are there and ready to answer you and so on.
> 2) you don't see anymore if a fragment is lost 'til it's too late. Plus
> you'll need timers to handle the fragment timeout, like IPv6 does,
> 3) more headaches I've forgotten.
>
> So, design choices. The one I love less to be honest, as the answer is
> always the same: try 'em all, and it means that I'll have to implement 'em
> all.
>
> BTW, if you're wondering... I'm implementing 6LoWPAN for the ns-3 network
> simulator, so my questions are due to the fact that I need to be close
> enough to what has been implemented to be realistic, but I need as well to
> be able to explore other design choices. My reference atm is Contiki as we
> do have a small testbed (a real one) with Contiki operated nodes. I know
> Cooja can simulate nodes, but again, there are a number of reasons to use a
> more general network simulator.
> Moreover I have a scientific project going on that will use WSN with IPv6,
> and we need to evaluate the design choices we can do for it.
>
> Anyway, thanks for your time. More code to write, not a biggie.
>
> Cheers,
>
> Tommaso
>
>
> On 13 Jan 2012, at 19:26, Colin O'Flynn wrote:
>
> Ciao Tommaso,
>
> As I haven’t seen anyone else talk about this, thought I’d take a stab…
>
> #1) Mesh-over isn’t a normally used phrase I know of. Normally it’s
> referred to either as mesh-under, where mesh routing is done at the layer
> below IP (MAC basically), or route-over, where routing is done at the IP
> layer.
>
> #2) The choice to pass the fragments all along as-is or not depends on a
> lot of things. It’s more efficient in general to just pass the fragments
> along, especially if you will only be using mesh-under. But if your code
> might support route-over, you need to reassemble at every hop. So perhaps
> the reasoning in Contiki is that because we support both, it’s easier to
> just have one code-base.
>
> There are other trade-offs too. Reassembling at every hop would tell you
> when you’ve lost a packet and are screwed, so can just stop forwarding the
> frame. One could make the case this lessens the burden of suffering from a
> malfunctioning/poorly linked node which never sends complete fragments,
> since only the node closest to this malfunctioning node wastes it’s time
> waiting for frames which never arrive. The rest of the network is shielded
> from these incomplete frames. I’m not saying that is the reason to always
> reassemble at every step, but there is advantages to each side…
>
> Warm Regards,
>
>   -Colin O’Flynn
>
> *From:* Tommaso Pecorella [mailto:tpe...@me...]
> *Sent:* January 12, 2012 6:23 PM
> *To:* con...@li...
> *Subject:* [Contiki-developers] 6LoWPAN fragmentation and reassembly
>
> Hi all,
>
> noobie question, but ... I'm puzzled about how reassembly is done in
> 6LoWPAN.
>
> If I read right the code, all the nodes are reassembling a fragmented
> packet, then sending it again (possibly fragmented).
>
> Any specific reason about not sending it as it is, (i.e., already
> fragmented) and leaving the reassembly burden to the final destination ?
>
> Of course I'm referring to a mesh-over case.
>
> Thanks,
>
>
> Tommaso
>
>
> -----------------------------------------------------------------
>
> Tommaso Pecorella - Ph.D.
>
>
>
> Assistant professor
>
> Dpt. Elettronica e Telecomunicazioni
>
> Università di Firenze
>
>
>
> CNIT - Università di Firenze Unit
>
>
>
> via di S. Marta 3
>
> 50139, Firenze
>
> ITALY
>
>
>
> email: tom...@un...
>
>        tom...@cn...
>
>
>
> phone : +39-055-4796412
>
> mobile: +39-320-4379803
>
> fax   : +39-055-494569
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
>
> http://p.sf.net/sfu/rsa-sfdev2dev2_______________________________________________
> Contiki-developers mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/contiki-developers
>
>
> --------------------------------------------------------------
>
> Thinking evolution:
>  "To be is to do" - Socrates
>  "To do is to be" - Sartre
>  "Do Be Do Be Do" - Sinatra
>  "Scooby Dooby Do" - Scooby Do
>  "Yaba Daba Doo!" - Fred Flintstone
>
> --------------------------------------------------------------
>
> Tommaso Pecorella - Ph.D.
>
> Assistant professor
> Dpt. Elettronica e Telecomunicazioni
> Università di Firenze
>
> CNIT - Università di Firenze Unit
>
> via di S. Marta 3
> 50139, Firenze
> ITALY
>
> email: tom...@un...
>        tom...@cn...
>
> phone : +39-055-4796412
> mobile: +39-320-4379803
> fax   : +39-055-494569
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> _______________________________________________
> Contiki-developers mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/contiki-developers
>
>