Re: [6tisch] [Roll] Intention for draft-thubert-roll-forwarding-frags

[Carsten Bormann <[e-mail]>]

> There are really 2 pieces in the draft, the 'trick' to forward a fragment and that can be implemented independently and transparently by every node, so there is no need for standardization and I could go ahead with an informational personal submission to the RFC editor - better have an RFC number than a lost in space personal submission.

Yep. Good point.

I think the first formal documentation of this technique is in the 6LoWPAN book, section 2.5.2 (L3 routing (“Route-Over”), page 40/41).

For the IETF, it is documented in draft-ietf-lwig-guidance, section 3.1.1.

Do you have anything that needs to be added to the guidance document about this?
(Or about any other implementation technique important for 6LoWPAN?
Once lwig-terminology is done, I’d like to start wrapping up the guidance document.)

> And then there is the capability to retry and do flow control over fragment on a multihop forwarding plane. Forwarding fragments has this side effect that 1 hop ARQ in the middle of a multihop forwarding plane does not let the fragment source know that a fragment was abandoned somewhere on the way. Incomplete packets are a bad idea in a constrained node. Whether it is a good idea to protect fragments end-to -end over the multihop LLN as opposed *or* on top of every hop is debatable. Carsten opposes, and there were a number of other knee-jerk reactions. But we need a people who understand forwarding and transport to make the decision.

Right now, what we have is a clash of intuitions.  Many people are thinking “won’t work”, “not needed”, “doesn’t improve”.  Others are thinking that the new mechanisms would help.
As I said before, the only way to resolve this is getting data.

Grüße, Carsten