Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Jan 2017 09:15:09 +0000

Hello Michel

I published a 04 addressing your comments. Please let us know if you find more improvements to be made on the draft.

A new version of I-D, draft-thubert-6lo-forwarding-fragments-04.txt

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

Name:                  draft-thubert-6lo-forwarding-fragments

Revision:              04

Title:                     LLN Fragment Forwarding and Recovery

Document date:               2017-01-10

Group:                  Individual Submission

Pages:                  16

URL:            https://www.ietf.org/internet-drafts/draft-thubert-6lo-forwarding-fragments-04.txt

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

Htmlized:       https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-04

Diff:           https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-forwarding-fragments-04

Abstract:

   In order to be routed, a fragmented 6LoWPAN 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

Happy new year!

Pascal

From: 6lo [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 23 décembre 2016 19:34
To: Michel Veillette <[email-masked]>; [email-masked]
Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review

Thanks a bunch for your review, Michel!

I'll update the doc accordingly early next year.

The fragmentation and the forwarding of fragments are finally getting a hot topic, and was discussed at the last 6TiSCH interim.
I'll probably present on the draft and the rationale behind some of the technical choices therein at the next interim on Jan 6th, 7AM pacific, if you can attend?

Take care,

Pascal

From: 6lo [mailto:[email-masked]] On Behalf Of Michel Veillette
Sent: jeudi 22 décembre 2016 18:21
To: [email-masked]<mailto:[email-masked]>
Subject: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review

Hi Pascal

First, I'll like to mention that your draft [I-D.-thubert-6lo-forwarding-fragments] is very appreciated.
This draft addresses multiple issues associated to the transfer of large payloads.
- Minimize frame overhead.
- Increase efficiency and reduce latency compared to a reassembly at each router.
- Complementary to the concept of TSCH tracks.
- Guaranty a fix routing during the transfer which often result in a more deterministic performance.

The following properties defined in this draft are important to us and need to be preserved.
- End to end transfer of 6lo fragment without reassembly at each router
- Optional use of acknowledgment and retries
- Support of multiple fragments in transit
- Label based routing

These are my comments on the current version.

1) datagram tag
I recommend that you globally replace "datagram tag" with a space by "datagram_tag" with an underscore
to clearly indicate that you refer to the field within RFRAG.

2) Typo
Section 8.1, second line, replace "adnd" by "and"

3) Reference to ND
In section 8.1, I recommend that you remove the reference to ND in "a ND resolution to get the MAC address
associated to IP_nxt".  Some stacks don't use ND to perform this function.

4)  label routing
Is it possible to extend the concept of label based routing to subsequent IP packets part of the same flow
in both directions (upstream and downstream)?
The issue I want to resolve is the following. In an RPL non storing mode network, the 6LBR can create an alternate
source route to go around a non functional router. This approach forces a route downstream, but not upstream
unless the source route is replayed on the reverse direction.
Can we define a new field (label), distinct from the datagram_tag, with a lifespan longer than a single IP packet
transfer and used to perform this label based routing?
Any suggestions to resolve this issue is appreciated.

Regards,

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-531-3109

---

From: Michel Veillette <[email-masked]>
Date: Tue, 10 Jan 2017 15:30:05 +0000

Hi Pascal

About my last topic (how to extend the use of label routing for subsequent downstream or upstream IP packets), do you have an approach to propose? This solution can be within the context of this draft or an existing RFC. Is there a synergy possible between the need to maintain a route during the transfer of a fragmented IP packet, the need to maintain a route during an interaction between two nodes, the notion of TSCH track?

Thanks for the draft update.

Regards
Michel

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Tuesday, January 10, 2017 4:15 AM
To: Michel Veillette <[email-masked]>; [email-masked]
Subject: RE: [I-D.-thubert-6lo-forwarding-fragments] review

Hello Michel

Revision:              04

Pages:                  16

Abstract:

Happy new year!

Pascal

From: 6lo [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 23 décembre 2016 19:34
To: Michel Veillette <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review

Take care,

Pascal

Hi Pascal

1) datagram tag

2) Typo

3) Reference to ND

4)  label routing

Regards,

Michel Veillette

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Jan 2017 15:36:49 +0000

Hello Michel :

The 6TiSCH architecture suggests to identify flows by the source of destination address, plus a local instance ID which is compressed by 6LoRH.
When you use 6TiSCH tracks, the G-MPLS operation allows to forward fragments along a path without the need of the the datagram_tag switching that is presented in the draft, the whole track is indeed a tunnel that appears as one hop for 6LoWPAN.

Do we need to define something new/different?

Take care,

Pascal

From: Michel Veillette [mailto:[email-masked]]
Sent: mardi 10 janvier 2017 16:30
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Subject: RE: [I-D.-thubert-6lo-forwarding-fragments] review

Hi Pascal

Regards
Michel

Hello Michel

Revision:              04

Pages:                  16

Abstract:

Happy new year!

Pascal

Take care,

Pascal

Hi Pascal

1) datagram tag

2) Typo

3) Reference to ND

4)  label routing

Regards,

Michel Veillette