Subject: [6lo] 6lowpan Fragmentation design team interest?

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 18 Jul 2017 09:34:00 -0700

Dear all:

At IETF99 6lo wg meeting 6lo-chairs discussed a few questions in order to
sense WG interests for further work on fragmentation - especially for
route-over topology.
The details charter for the design team will be finalized soon.
However, the 6lo-chairs are collecting names for the interested individuals
for the design team. We might need 4-5 person design team and prior
experience on packet forwarding is helpful.

We are requesting the following :
* Send your ideas to the list on what you want to see resolved by the
fragmentation design team

* If you have any prior experience on 6lowpan fragmentation work on
router-over or mesh-under please send information about it

Thanks,
Gabriel & Samita

Reference slides from today's session:

https://www.ietf.org/proceedings/99/slides/slides-99-6lo-wg-discussion-questions-on-6lo-fragmentation-work-and-scoping-01.pdf

https://www.ietf.org/proceedings/99/slides/slides-99-6lo-6lowpan-fragment-forwarding-in-route-over-multi-hop-topology-00.pdf

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 19 Jul 2017 10:40:27 +0200

Thanks Chairs/Pascal/Carles for getting fragmentation issue on the
forefront!

My take on handling the issue would be:
1. Check what best can be achieved with single buffer policy
2. Check what improvements can be achieved if a standby (but pooled) buffer
is allocated for managing fragmentation and put up signalling/routing
changes .... may be fragment-forwarding can help here.
3. Make above two compatible with each other
4. Identify implications of changing the routing behaviour for fragments on
intermediate 6LRs... Like Carsten said, the current routing has been there
for long and that might have lead to some ossification! (May be this should
be first on the agenda item)
5. Put up "realistic RF simulation and hardware testbed" for experimenting
... Cannot rely on Cooja for this.

Regarding my interest/experience/deployment scenario, I had mentioned this
on ML before in the same context (
https://www.ietf.org/mail-archive/web/6lo/current/msg02365.html). I can
help with the design/review/experimentation.

Regards,
Rahul

On 18 July 2017 at 18:34, Samita Chakrabarti <[email-masked]> wrote:

> However, the 6lo-chairs are collecting names for the interested
> individuals for the design team. We might need 4-5 person design team and
> prior experience on packet forwarding is helpful.
>
> https://www.ietf.org/proceedings/99/slides/slides-99-6lo-wg-discussion-
> questions-on-6lo-fragmentation-work-and-scoping-01.pdf
>
> https://www.ietf.org/proceedings/99/slides/slides-99-6lo-6lowpan-fragment-
> forwarding-in-route-over-multi-hop-topology-00.pdf
>
>
>
>
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Jul 2017 15:53:20 +0200

We need to do at least the first two of three things:

(1) Write up how fragment forwarding works today (those implementation techniques are currently not documented in a way that is very accessible to new implementers).

(2) Look at the timing considerations governing burst packet transmission to a forwarder and paced fragment forwarding.  Can we derive guidelines for implementers or even standardize something (BCP or PS level)?  This requires finding (and possibly conducting) pertinent research.

(3) Look at the use cases that would benefit from multi-hop fragment retransmission (we have fragment retransmission today, but only single-hop, and only for unicast).  If we find any such use cases, document their characteristics, and try to find solutions that have ways to resolve interactions with (2) and with transport-layer retransmission timers.  This requires way more research.

We also could look at better supporting ECN and other issues that come up in tunneling-like environments.

Grüße, Carsten

> On Jul 18, 2017, at 18:34, Samita Chakrabarti <[email-masked]> wrote:
> 
> Dear all:
> 
> At IETF99 6lo wg meeting 6lo-chairs discussed a few questions in order to sense WG interests for further work on fragmentation - especially for route-over topology.
> However, the 6lo-chairs are collecting names for the interested individuals for the design team. We might need 4-5 person design team and prior experience on packet forwarding is helpful.
> 
> * Send your ideas to the list on what you want to see resolved by the fragmentation design team 
> 
> * If you have any prior experience on 6lowpan fragmentation work on router-over or mesh-under please send information about it
> 
> Thanks,
> Gabriel & Samita
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Jul 2017 02:45:52 -0500

Hi Pascal,

Is fragmentation an issue in lpwan also?
If yes, maybe a joint DT can be formed.

Another question: I think we are talking about 802.15.4 maximum frame size
of 127 limitation here, is that right?

Regards,

Behcet

On Wed, Jul 19, 2017 at 8:53 AM, Carsten Bormann <[email-masked]> wrote:

> (1) Write up how fragment forwarding works today (those implementation
> techniques are currently not documented in a way that is very accessible to
> new implementers).
>
> (2) Look at the timing considerations governing burst packet transmission
> to a forwarder and paced fragment forwarding.  Can we derive guidelines for
> implementers or even standardize something (BCP or PS level)?  This
> requires finding (and possibly conducting) pertinent research.
>
> (3) Look at the use cases that would benefit from multi-hop fragment
> retransmission (we have fragment retransmission today, but only single-hop,
> and only for unicast).  If we find any such use cases, document their
> characteristics, and try to find solutions that have ways to resolve
> interactions with (2) and with transport-layer retransmission timers.  This
> requires way more research.
>
> > At IETF99 6lo wg meeting 6lo-chairs discussed a few questions in order
> to sense WG interests for further work on fragmentation - especially for
> route-over topology.
> > https://www.ietf.org/proceedings/99/slides/slides-
> 99-6lo-6lowpan-fragment-forwarding-in-route-over-multi-hop-topology-00.pdf
> >
> >
> >
> >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Jul 2017 07:51:21 +0000

Hello Behcet :

The LPWAN solution is part of the SCHC document and is now very close to last call.
The basis of bitmap ack is common but there are also differences in the problem space du to frame size and meshing.
So the commonality only goes so far…

Take care;

Pascal

From: 6lo [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: jeudi 20 juillet 2017 09:46
To: Carsten Bormann <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>; Samita Chakrabarti <[email-masked]>; lo <[email-masked]>
Subject: Re: [6lo] 6lowpan Fragmentation design team interest?

Hi Pascal,
Is fragmentation an issue in lpwan also?
If yes, maybe a joint DT can be formed.
Another question: I think we are talking about 802.15.4 maximum frame size of 127 limitation here, is that right?
Regards,
Behcet

On Wed, Jul 19, 2017 at 8:53 AM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:
We need to do at least the first two of three things:

Grüße, Carsten

> On Jul 18, 2017, at 18:34, Samita Chakrabarti <[email-masked]<mailto:[email-masked]>> wrote:
>
> Dear all:
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Jul 2017 09:52:33 +0200

> On Jul 20, 2017, at 09:45, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi Pascal,
> 

Definitely, and there is a draft for that:

  LPWAN Static Context Header Compression (SCHC) and fragmentation for
                              IPv6 and UDP
               draft-ietf-lpwan-ipv6-static-context-hc-05

The tradeoffs are rather different there, so I’m not sure that the lpwan work applies to 6lo.

> Another question: I think we are talking about 802.15.4 maximum frame size of 127 limitation here, is that right?

The fragmentation scheme is general, but that number is the ballpark of the fragment size this would address (which is very different from LPWAN).

Grüße, Carsten