Subject: [6lo] FW: New Version Notification for draft-thubert-6lo-forwarding-fragments-02.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Nov 2014 15:54:39 +0000

Dear all:

I republished the draft, adding a little bit of text on self-interference between fragments.
I'd really love to see a community of people interested in solving the fragment issues, so we can make progress on the topic.
If this is your case, or if you think that fragments is not a problem (that can be solved) please speak up.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: mardi 25 novembre 2014 16:40
To: Jonathan Hui (johui); Pascal Thubert (pthubert); Jonathan Hui (johui); Pascal Thubert (pthubert)
Subject: New Version Notification for draft-thubert-6lo-forwarding-fragments-02.txt

A new version of I-D, draft-thubert-6lo-forwarding-fragments-02.txt
has been successfully submitted by Pascal Thubert and posted to the IETF repository.

Name:		draft-thubert-6lo-forwarding-fragments
Revision:	02
Title:		LLN Fragment Forwarding and Recovery
Document date:	2014-11-25
Group:		Individual Submission
Pages:		16
URL:            http://www.ietf.org/internet-drafts/draft-thubert-6lo-forwarding-fragments-02.txt
Status:         https://datatracker.ietf.org/doc/draft-thubert-6lo-forwarding-fragments/
Htmlized:       http://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-forwarding-fragments-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.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Owen Kirby <[email-masked]>
Date: Tue, 25 Nov 2014 11:55:35 -0800

Pascal,

I'm not sold on the value of forwarding fragments, it doesn't 
fundamentally change the amount of data that needs to be sent over the 
air and introduces a great deal more complexity in the protocol for a 
somewhat unclear benefit. As soon as fragments are allow to travel more 
than one hop one needs to start dealing with multiple paths, 
non-deterministic RTT, and all sorts of complexity that could arise 
between the link-layer forwarding scheme to move fragments through the 
network and the IP routing scheme (for example, what happens if there 
was an IP routing header that didn't fit in the first fragment?).

However, I think that fragment recovery is a brilliant idea. Without 
some form of fragment recovery, the probability of loosing a packet 
increases exponentially with the number of fragments and even moderate 
frame loss rates can have a very dramatic effect on performance as a 
result.As RFC4944 currently stands, it only takes a single lost 
fragment, and the entire end-to-end packet needs to be resent, which can 
be very expensive when dealing with a large MTU.

Cheers,
Owen

On 14-11-25 07:54 AM, Pascal Thubert (pthubert) wrote:
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 27 Nov 2014 14:30:26 +0000

Well, that's already very cool, Owen.

Let me try, though, to convince you that forwarding the fragments is indeed advantageous, in particular, admittedly, in the context of 6TiSCH.

The discussion below comes from experience of actual ultimate congestion reached in networking devices under load, but the same is generically valid in multiple environments, including 6lowpan / rpl routers, where congestion will be reached even soon due to limited buffer capacity.

Say that a packet is cut in 3 6lowpan fragments, and there are 2 routers in between sender and listener.

Say they are all in a same interference domain so a packet cannot be forwarded at multiple hops in parallel.

In the tables below, I noted 'I' a fragment resident in memory and (I) a fragment pending ack to be freed from memory.

If we recompose at each hop, we get the picture below

Sender

Router 1

Router 2

Receiver

T=0

III

T=1

II(I)

I

T=2

I(I)

II

T=3

(I)

III

T=4

II(I)

I

T=5

I(I)

II

T=6

(I)

III

T=7

II(I)

I

T=8

I(I)

II

T=9

(I)

III

Now, if we forward the fragments without any streamlining because of the same interference domain assumption above:

Sender

Router 1

Router 2

Receiver

T=0

III

T=1

II(I)

I

T=2

II

(I)

I

T=3

II

(I)

I

T=4

I(I)

I

I

T=5

I

(I)

I

I

T=6

I

(I)

II

T=7

(I)

I

II

T=8

(I)

I

II

T=9

(I)

III

No magic, it takes the exact same time to forward the packet end to end in either case.

Yet, we can already see the major benefit of forwarding fragments, which is really that intermediate routers only store one fragment at a time, instead of peak of 3 in this case, up to 20+ in worst case.

This makes all the difference in the work for an intermediate router that is on the way of multiple flows. The router become rapidly unable to cope with multiple large packets which are dropped.

Behind this simple reasoning, there is the traditional wisdom that the network is the worst place to store your data.  This traditional wisdom is critical to LLN and should not be forgotten.

Now, if the interference domain is not an issue, such as is the case with 6TiSCH with the TSCH technology, then we can streamline as follows:

Sender

Router 1

Router 2

Receiver

T=0

III

T=1

II(I)

I

T=2

II

(I)

I

T=3

I(I)

I

(I)

I

T=4

I

(I)

I

I

T=5

(I)

I

(I)

II

T=6

(I)

I

II

T=7

(I)

III

T=8

T=9

At T=3, router 1 send the 1st fragment to router 2.

At T=4, the sender endpoint sends the second fragment to router 1 while at the same time router 2 sends the first fragment to the receiver endpoint.

It results that the overall need for buffers is still one per hop but the overall latency is now reduced.

Conclusion:

Forwarding fragments reduces 1) the need for buffers in the routers and 2) the latency. Both are quite critical benefits.

Make no mistake, these concepts are 1) important and 2) not new to LLNs in any fashion.

The issues were known and addressed in classical/legacy switched networks such as frame relay.

I actually attach some slideware that discusses some of the traditional switching wisdom that probably applies in a similar fashion in multi-hop LLN.

What would be extremely sad would be to rediscover those issues the hard way, by lack of historical background.

Cheers,

Pascal

PS ) Now, I can also draw a picture of what happens in the non-perfect case where retries are exhausted for a given fragment between 2 routers, in either mode.

I understand that you are already convinced that the end to end recovery is much needed. I'd add to it that flow control is also much needed, since there is no value pushing more fragments then there are non-hops in the network.

> From: 6lo [mailto:[email-masked]] On Behalf Of Owen Kirby

> Sent: mardi 25 novembre 2014 20:56

> To: [email-masked]

> Subject: Re: [6lo] FW: New Version Notification for draft-thubert-6lo-

> forwarding-fragments-02.txt

> > I republished the draft, adding a little bit of text on self-interference between

> fragments.

> > I'd really love to see a community of people interested in solving the fragment

> issues, so we can make progress on the topic.

> > If this is your case, or if you think that fragments is not a problem (that can be

> solved) please speak up.

> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

> > To: Jonathan Hui (johui); Pascal Thubert (pthubert); Jonathan Hui (johui); Pascal

> Thubert (pthubert)

> > Subject: New Version Notification for draft-thubert-6lo-forwarding-

> fragments-02.txt

> > has been successfully submitted by Pascal Thubert and posted to the IETF

> repository.

> > URL:            http://www.ietf.org/internet-drafts/draft-thubert-6lo-forwarding-<http://www.ietf.org/internet-drafts/draft-thubert-6lo-forwarding-fragments-02.txt>

> fragments-02.txt<http://www.ietf.org/internet-drafts/draft-thubert-6lo-forwarding-fragments-02.txt>

> > Status:         https://datatracker.ietf.org/doc/draft-thubert-6lo-forwarding-<https://datatracker.ietf.org/doc/draft-thubert-6lo-forwarding-fragments/>

> fragments/<https://datatracker.ietf.org/doc/draft-thubert-6lo-forwarding-fragments/>

> > Htmlized:       http://tools.ietf.org/html/draft-thubert-6lo-forwarding-<http://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-02>

> fragments-02<http://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-02>

> > Diff:           http://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-forwarding-<http://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-forwarding-fragments-02>

> fragments-02<http://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-forwarding-fragments-02>

> > Please note that it may take a couple of minutes from the time of submission

> until the htmlized version and diff are available at tools.ietf.org.

> > [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>