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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Feb 2014 08:48:31 +0000

Hello Michael:

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.

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.

FYI, small frames are here to stay, even though 802.15.4g is heavily used in smartgrid applciations; classical 15.4 2006 is still the base of industrial WSN protocols and, BTW, of 6TiSCH.

Cheers,

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: jeudi 6 février 2014 17:44
> To: Pascal Thubert (pthubert)
> Cc: Ines Robles; Jonathan Hui (johui); roll
> Subject: Re: Intention for draft-thubert-roll-forwarding-frags
> 
> 
> Pascal Thubert (pthubert) <[email-masked]> wrote:
>     > We presented the work at 6lo, but there was a mitigated reception.
> 
>     > Carsten in particular opposed the work, and complained that it moved
> places,
>     > plus has doubts about the retry mechanism.
> 
>     > Would you wish ROLL to continue that work?
> 
> We are not looking for new things, but rather trying to make sure that we
> haven't missed or ignored any relevant new work.  Some times a draft is written
> just to explain an idea, and that it doesn't need to go anywhere.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Feb 2014 12:32:16 +0100

> 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 co…

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 forw…

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2014 10:26:05 -0500

Carsten Bormann <[email-masked]> wrote:
    >> 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.

Sounds like experimental track to me.