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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Feb 2014 18:05:48 +0000

Hello Ines:

This is a draft that was initially at 6LoWPAN, but the WG was in flux and people at ROLL asked the authors to revive the draft so we presented it there.
It is related to ROLL in that it enables routing fragments but still it is a bit farfetched, unless ROLL recharters in that direction in the future.
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?

Cheers,

Pascal

From: Ines Robles [mailto:[email-masked]]
Sent: jeudi 23 janvier 2014 23:44
To: Pascal Thubert (pthubert); Jonathan Hui (johui)
Cc: Michael Richardson; roll
Subject: Intention for draft-thubert-roll-forwarding-frags

Hi Pascal and Jonathan,

Thank you very much for draft-thubert-roll-forwarding-frags-02,

Abstract:

In order to be routed, a fragmented packet must be reassembled at
  every hop of a multihop link where lower layer fragmentation occurs.
  Considering that the IPv6 minimum MTU is 1280 bytes and that an an
  802.15.4 frame can have a payload limited to 74 bytes in the worst
  case, a packet might end up fragmented into as many as 18 fragments
  at the 6LoWPAN shim layer.  If a single one of those fragments is
  lost in transmission, all fragments must be resent, further
  contributing to the congestion that might have caused the initial
  packet loss.  This draft introduces a simple protocol to forward and
  recover individual fragments that might be lost over multiple hops
  between 6LoWPAN endpoints.

We would like to know please how you see that this draft is aligned with the roll charter,

it seems that the intention is in this thread: http://www.ietf.org/mail-archive/web/roll/current/msg07784.html, is that correct? do you have some additional information for intention?

Thank you in advance,

Michael and Ines.

---

From: Ines Robles <[email-masked]>
Date: Wed, 5 Feb 2014 19:01:56 -0200

Hi Pascal,

Thank you for your reply.

Please correct me if I am wrong, It seems to me that the routing fragments
are not aligned with the current roll charter.

In case that we do a roll-rechartering we could discuss whether integrate
this draft or not. Independent of the result, we want to say thank you very
much for your hard work put in this document.

Please any comments are very welcome,

Kind Regards,

Ines.

2014-02-05 Pascal Thubert (pthubert) <[email-masked]>:

>  Hello Ines:
>
>
>
> This is a draft that was initially at 6LoWPAN, but the WG was in flux and
> people at ROLL asked the authors to revive the draft so we presented it
> there.
>
> It is related to ROLL in that it enables routing fragments but still it is
> a bit farfetched, unless ROLL recharters in that direction in the future.
>
> Carsten in particular opposed the work, and complained that it moved
> places, plus has doubts about the retry mechanism.
>
>
>
> *From:* Ines Robles [mailto:[email-masked]]
> *Sent:* jeudi 23 janvier 2014 23:44
> *To:* Pascal Thubert (pthubert); Jonathan Hui (johui)
> *Cc:* Michael Richardson; roll
> *Subject:* Intention for draft-thubert-roll-forwarding-frags
>
>
>
> Hi Pascal and Jonathan,
>
>
>
> it seems that the intention is in this thread:
> http://www.ietf.org/mail-archive/web/roll/current/msg07784.html, is that
> correct? do you have some additional information for intention?
>
>
>
> Thank you in advance,
>
>
> Michael and Ines.
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 5 Feb 2014 22:14:12 +0100

On 05 Feb 2014, at 19:05, Pascal Thubert (pthubert) <[email-masked]> wrote:

> Carsten in particular opposed the work, and complained that it moved places,

Well, my complaint was not just about the fact that the same idea had been discussed in several places, but mainly that it already had received lukewarm to negative feedback in those places, but there had been little progress in the draft apparent when it turned up in the next place.

> plus has doubts about the retry mechanism

That is really the technical part of my and others’ skepticism.
Apart from the apparent redundancy with existing L2 ACK/retransmission mechanisms, one aspect was the unclear interaction of a multi-hop reliability scheme with transport timers.
More generally, there was skepticism that this approach actually yields improvements that are in line with the complexity it creates.
Having some observations from simulations or preferably real networks would be useful to dispel this impression.

But I agree with Ines, sub-IP encapsulation and reliability/performance is really outside ROLL’s scope.  6lo would actually be the right WG, but the technical question marks mentioned above would need to be addressed.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Feb 2014 11:43:36 -0500

> 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: "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
> 
> 
> places,
> 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.
> 
> --

---

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.

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 7 Feb 2014 14:05:45 -0500

> From: Carsten Bormann <[email-masked]>
> Date: Fri, 7 Feb 2014 12:32:16 +0100
> 
>   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.
> 
> thinking that the new mechanisms would help.  As I said before, the
> only way to resolve this is getting data.

My experience with 802.15.4 has been that end-to-end
acknowledgements are necessary to get good reliability in a
multihop network.  We have tried to get along without them, but
in the end we always go back.  Packets go astray in some way or
other that requires a positive action to fix, so you have to know
when something has gone wrong in order to kick off a fix.  The
best and simplest solution is to have end-to-end acks within the
mesh, operating below the transport layer (the transport layer
has its own problems to worry about, and one or both endpoints
may be outside the mesh anyway).

So I would say that something is needed, but I am not sure that
the on-hop acks in draft-thubert-roll-forwarding-frags are the
solution.  There may be a way to extend the runt buffer
trick to get an ack all the way back; it couldn't be done
transparently though.  You could stick a mesh header on the
front and use MPLS-like forwarding to make it look like one
hop to the fragmentation code.  Or something.

                                 -Richard Kelsey
This email and any attachments may be confidential. If so, do not disseminate without the senderâ€™s authorization. If you are not the intended recipient, please delete it and notify the sender. Email transmissions cannot be guaranteed to be error-free or virus-free and we accept no liability. Silicon Labs does not intend or authorize emails to act as legally binding contracts.