Re: [6tisch] [6lo] Thomas' review of draft-thubert-6lo-forwarding-fragments-04

[Carsten Bormann <[e-mail]>]

>>> The major rationale IMO for this draft is that it doesn't require intermediary nodes to reassemble!
>> 
>> As I said in the WG meeting (and pointed out in the 6LoWPAN book), this has not really been necessary even in the original 6LoWPAN.  However, to make “virtual reassembly buffers” work in multi-track environments, the first fragment (which provides the routing info) has to be sent on all tracks.
> 
> I think I understand the technique you are describing.  Is there a written guideline or specification for the technique somewhere?

Apart from the brief description in section 2.5.2 of the 6LoWPAN book, I’m not aware of a writeup.
As I said at the meeting, maybe we should do that (food for lwig?).

> I don't recognize the term "multi-track environment".  Can you define it for me?

I was thinking about an environment where your routing protocol might cause different fragments to go different paths, or even to send copies of some fragments along multiple paths.

>>> The label switching mechanism is elegant as the labels are locally significant only, with no need to maintain a network-wide label registry. The document should state so.
>> 
>> Yes, that is the idea behind datagram tags in RFC 4944 — they are local to the hop.  Viewing the set of “virtual reassembly buffers” as a label switching table is certainly one way to describe it.  Still, this is an implementation technique for RFC 4944 6LoWPAN fragmentation, not a new protocol.
> 
> In particular, I think I can infer how datagram tags would be used in a hop-scoped way with virtual reassembly buffers.  It would be good to have text to work through the details.  

Basically, a virtual reassembly buffer maps a incoming neighbor MAC address and an incoming datagram tag to an outgoing neighbor MAC address and an outgoing datagram tag.
It is created when an initial fragment is being processed and forwarded.  It could be deleted on forwarding the final fragment and/or on a timeout and/or on displacement.
(It could record more information, such as the target IP address that went into selecting the outgoing MAC address.)
It may also be useful to keep some management information (as in RFC 7388).
Finally, in certain cases it may keep fragments of a fragment in order to optimize re-fragmenting (but it generally is better to have the original fragmenter minimize the size of the *initial* fragment so no re-fragmenting is necessary even if header compression rates change).

Grüße, Carsten