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

[Richard Kelsey <[e-mail]>]

> From: Carsten Bormann <[e-mail]>
> Date: Fri, 7 Feb 2014 12:32:16 +0100
> 
> > 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.

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.