Subject: [6tisch] Fwd: Comparison of 6lo-rpl drafts

From: Martin Turon <[email-masked]>
Date: Sun, 14 Sep 2014 11:19:43 -0700

Martin

Begin forwarded message:

> From: Martin Turon <[email-masked]>
> Date: September 12, 2014 at 12:09:58 PM PDT
> To: [email-masked]
> Subject: Comparison of 6lo-rpl drafts
> 
> Dear 6lo Group,
> 
> On the 6tsch call today, we reviewed and compared the two drafts within 6lo that deal with the topic of compressing RPL routing options or "hints":
> 
> draft-bormann-6lo-rpl-mesh
> draft-thubert-6lo-rpl-nhc
> 
> I was asked to forward my comments to this group.  
> 
> While RPL is very popular routing protocol currently in use with many 6lo deployments, it seems dangerous to bake a specific routing protocol too deeply into the IPv6 header compression.  We don't know what routing protocols people will want to run on top of 6lo in tens years time.  The header compression scheme should be flexible enough to handle passing hints for various routing protocols, and possibly multiple.   Allocating portions of the dispatch byte to anything other than very generic facilities should be strongly discouraged.
> 
> In the two proposals, draft-bormann adds an rpl specific mesh header in the dispatch byte, and draft-thubert adds a rpl specific option in the next header dispatch byte. The next header approach aligns much better with the extensible design preference outlined above.  
> 
> All proposals for rpl extensions should be assessed by whether they create a good design pattern which other routing protocols could follow to compress their own protocol specific options.  How many other routing protocols would be able to follow a similar design path?  Also, allocation of the dispatch byte for protocol specific compression as described in draft-bormann should be heavily discouraged.
> 
> Even in a LOWPAN_NHC approach, the introduction of "compressed routing options" should be done in an extensible way that envisions other future routing protocols other then RPL.  The question is how will this range be utilized going forward:
> 
>    00000000 to 11011111: (unassigned)
>      1110000N: IPv6 Hop-by-Hop Options Header       [RFC6282]
>      1110001N: IPv6 Routing Header                  [RFC6282]
>      1110010N: IPv6 Fragment Header                 [RFC6282]
>      1110011N: IPv6 Destination Options Header      [RFC6282]
>      1110100N: IPv6 Mobility Header                 [RFC6282]
>      1110111N: IPv6 Header                          [RFC6282]
>      11110CPP: UDP Header                           [RFC6282]
>      11111000 to 11111110: (unassigned)
> 
> It would seem natural to formally allocate a portion of the range for "compressed hop-by-hop" or "compressed routing" headers:
> 
>      1101000N: IPv6 Compressed Hop-by-Hop Header (LOWPAN_NHC_HBH)       
>      1101001N: IPv6 Compressed Routing Header    (LOWPAN_NHC_ROT)
> 
> Regards,
> Martin
> _____________________________
> Martin Turon  |  Nest Labs
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 16 Sep 2014 22:08:44 +0200

Hi Martin, all,

I support Martin vision in the sense that now we cannot take specific
decisions for specific routing protocols without leaving some space for
future improvements or directions.

for clarification this are the documents we are discussing:

draft-bormann-6lo-rpl-mesh
draft-thubert-6lo-rpl-nhc
draft-thubert-6man-flow-label-for-rpl

For me the most natural approach is to have 6lowpan compress any header
following IPHC header (as done with UDP, ICMP, etc..) and use N to indicate
a Next header. In that way, headers can be parsed sequentially using the
same methodology. The approach in
draft-thubert-6lo-rpl-nhc
seems less complex as the HbH flags are not overloading other bits in the
IPHC header

The flow label approach instead is clever and uses a wasted space in the
packet, but I am worried about whether we should use that space for that
specific purpose. Besides, and leaving appart the long discussion we had
about if this violates some MUST/SHOULD statement,   I'm wondering if going
at that direction would require to have some bits of the flow label to
encode what information is stored there (like a dispatch option) so we can
overload that space in the header with other information different that the
RPL HbH header, this might require some other fields (e.g rpl Instance Id
to be compressed).

Finally from an implementer perspective the flow-label approach it is very
easy to integrate and requires very little changes to the code.

my 5 cents.
regards,
Xavi

2014-09-14 20:19 GMT+02:00 Martin Turon <[email-masked]>:

>
>
> Martin
>
> Begin forwarded message:
>
> *From:* Martin Turon <[email-masked]>
> *Date:* September 12, 2014 at 12:09:58 PM PDT
> *To:* [email-masked]
> *Subject:* *Comparison of 6lo-rpl drafts*
>
> Dear 6lo Group,
>
> On the 6tsch call today, we reviewed and compared the two drafts within
> 6lo that deal with the topic of compressing RPL routing options or "hints":
>
> <http://tools.ietf.org/id/draft-bormann-6lo-rpl-mesh-01.txt>
> <http://tools.ietf.org/id/draft-thubert-6lo-rpl-nhc-01.txt>
>
> While RPL is very popular routing protocol currently in use with many 6lo
> deployments, it seems dangerous to bake a specific routing protocol too
> deeply into the IPv6 header compression.  We don't know what routing
> protocols people will want to run on top of 6lo in tens years time.  The
> header compression scheme should be flexible enough to handle passing hints
> for various routing protocols, and possibly multiple.   Allocating portions
> of the dispatch byte to anything other than very generic facilities should
> be strongly discouraged.
>
> In the two proposals, draft-bormann adds an rpl specific mesh header in
> the dispatch byte, and draft-thubert adds a rpl specific option in the next
> header dispatch byte. The next header approach aligns much better with the
> extensible design preference outlined above.
>
> All proposals for rpl extensions should be assessed by whether they create
> a good design pattern which other routing protocols could follow to
> compress their own protocol specific options.  How many other routing
> protocols would be able to follow a similar design path?  Also, allocation
> of the dispatch byte for protocol specific compression as described in
> draft-bormann should be heavily discouraged.
>
> Even in a LOWPAN_NHC approach, the introduction of "compressed routing
> options" should be done in an extensible way that envisions other future
> routing protocols other then RPL.  The question is how will this range be
> utilized going forward:
>
>      1110000N: IPv6 Hop-by-Hop Options Header       [RFC6282 <http://tools.ietf.org/html/rfc6282>]
>      1110001N: IPv6 Routing Header                  [RFC6282 <http://tools.ietf.org/html/rfc6282>]
>      1110010N: IPv6 Fragment Header                 [RFC6282 <http://tools.ietf.org/html/rfc6282>]
>      1110011N: IPv6 Destination Options Header      [RFC6282 <http://tools.ietf.org/html/rfc6282>]
>      1110100N: IPv6 Mobility Header                 [RFC6282 <http://tools.ietf.org/html/rfc6282>]
>      1110111N: IPv6 Header                          [RFC6282 <http://tools.ietf.org/html/rfc6282>]
>      11110CPP: UDP Header                           [RFC6282 <http://tools.ietf.org/html/rfc6282>]
> It would seem natural to formally allocate a portion of the range for
> "compressed hop-by-hop" or "compressed routing" headers:
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 16 Sep 2014 22:58:30 +0200

Hi Pascal,

being back in the office, I have now looked at draft-thubert-6lo-rpl-nhc-01.
Section 4/5 works for me: this is a nicer solution than the one I derived.
(As with my draft, some additional text is needed to discuss how a hbh header that contains a RPL option beside other hbh option(s) is to be handled.)

Honestly, I’m not so hot about the verbiage in Section 1/2 of the draft.
If we could get a draft that just contains the parts that need consensus, I could mark draft-bormann-6lo-rpl-mesh-01.txt as replaced-by that updated version, removing some of the current confusion about the way forward on this.

Using up 1/4 of the RFC 6282 NHC space for the RPL hbh option strikes me as expensive, even if we only have used ~ 1/8 of that space yet (GHC will need ~ another 1/16).
(I think this is the essence of Martin’s comment, too.)
If we want to work further on this draft, we should look for ways moving this down to, say, 1/8, without unduly increasing complexity.
E.g., we could get rid of the forwarding-error bit, as that applies to storing mode only (we could use one additional NHC code, followed by the rest of the NHC code, to indicate a forwarding-error if people really think storing mode needs to be kept alive).

Note that we’ll need another chunk of the NHC space to compress RFC 6554, so the total usage for RPL will be even higher.  (I tried to initiate the discussion for this with my question whether we need to stick with the reversible “segments left” model of RFC 6554 or can discard addresses that have been traversed.  If nobody has an opinion on this, I might want to go ahead and propose something.)

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 17 Sep 2014 05:46:46 +0000

Hello Xavi and Martin:

Your point below on the flow label echoes Martin’s statement at the call on Friday. We must leave room for the Flow Label to be used but other protocols (eg routing).

My suggestion is to mimic what the 6lowpan dispatch did in 802.15.4 (see NALP in RFC 4944 page 9) in having the first bit of the Flow Label set if the FL is used by RPL (we have one free bit there). The would be the start if the definition of the flow label in LLNs. First bit on, RPL. First bit off, open for the future.

Would that float?

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: mardi 16 septembre 2014 22:09
To: Martin Turon
Cc: Pascal Thubert (pthubert); [email-masked]; [email-masked]
Subject: Re: [6tisch] Fwd: Comparison of 6lo-rpl drafts

Hi Martin, all,

I support Martin vision in the sense that now we cannot take specific decisions for specific routing protocols without leaving some space for future improvements or directions.

For me the most natural approach is to have 6lowpan compress any header following IPHC header (as done with UDP, ICMP, etc..) and use N to indicate a Next header. In that way, headers can be parsed sequentially using the same methodology. The approach in
draft-thubert-6lo-rpl-nhc
seems less complex as the HbH flags are not overloading other bits in the IPHC header

The flow label approach instead is clever and uses a wasted space in the packet, but I am worried about whether we should use that space for that specific purpose. Besides, and leaving appart the long discussion we had about if this violates some MUST/SHOULD statement,   I'm wondering if going at that direction would require to have some bits of the flow label to encode what information is stored there (like a dispatch option) so we can overload that space in the header with other information different that the RPL HbH header, this might require some other fields (e.g rpl Instance Id to be compressed).

Finally from an implementer perspective the flow-label approach it is very easy to integrate and requires very little changes to the code.

my 5 cents.
regards,
Xavi

2014-09-14 20:19 GMT+02:00 Martin Turon <[email-masked]<mailto:[email-masked]>>:

Martin

Begin forwarded message:
From: Martin Turon <[email-masked]<mailto:[email-masked]>>
Date: September 12, 2014 at 12:09:58 PM PDT
To: [email-masked]<mailto:[email-masked]>
Subject: Comparison of 6lo-rpl drafts
Dear 6lo Group,

draft-bormann-6lo-rpl-mesh<http://tools.ietf.org/id/draft-bormann-6lo-rpl-mesh-01.txt>
draft-thubert-6lo-rpl-nhc<http://tools.ietf.org/id/draft-thubert-6lo-rpl-nhc-01.txt>

     1110000N: IPv6 Hop-by-Hop Options Header       [RFC6282<http://tools.ietf.org/html/rfc6282>]

     1110001N: IPv6 Routing Header                  [RFC6282<http://tools.ietf.org/html/rfc6282>]

     1110010N: IPv6 Fragment Header                 [RFC6282<http://tools.ietf.org/html/rfc6282>]

     1110011N: IPv6 Destination Options Header      [RFC6282<http://tools.ietf.org/html/rfc6282>]

     1110100N: IPv6 Mobility Header                 [RFC6282<http://tools.ietf.org/html/rfc6282>]

     1110111N: IPv6 Header                          [RFC6282<http://tools.ietf.org/html/rfc6282>]

     11110CPP: UDP Header                           [RFC6282<http://tools.ietf.org/html/rfc6282>]

Regards,
Martin

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Sep 2014 08:41:39 +0200

On 17 Sep 2014, at 07:46, Pascal Thubert (pthubert) <[email-masked]> wrote:

> we have one free bit there

It’s not free, all 20 bits of the flow label are the flow label.

(Again, we can argue dedicating the field that way in 1994, and keeping it that way even while nibbling off bits for other uses, was bad protocol design, but that’s water under the bridge.)

I would prefer to stop wasting time on trying to hijack the flow label and instead finish the work on an NHC representation.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 17 Sep 2014 07:48:40 +0000

Hello Carsten:

The split and domain-dependent use of the Flow Label field was still on the table in the RFC 6437 discussions. This was rejected as a general rule but we still need an exception to RFC 6437 for LLNs so let us see what we get there.

I can still agree with you to progress on a 6lo NHC proposal and produce the best personal submission we can for WG evaluation. This in turn does not mean that 6lo will adopt the work or that ROLL will favor that option. 

I suggest we focus discussions on the relevant MLs:
- 6MAN on whether we can avoid having to set and/or carry a field of randomized 20 bits in the LLN  then eventually rewrite it for LLN purpose
- ROLL to decide whether to use a ROLL solution (based on FL is the only one on the table) or wait for 6lo to deliver
- 6Lo to decide whether and how to compress the RPL option (3 proposals on the table)

In any case copying 6TiSCH, which depends on the overall result to deliver the minimal draft, is a good idea.

Cheers,

Pascal

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]]
> Sent: mercredi 17 septembre 2014 08:42
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [6lo] [6tisch] Fwd: Comparison of 6lo-rpl drafts
> 
> It's not free, all 20 bits of the flow label are the flow label.
> 
> (Again, we can argue dedicating the field that way in 1994, and keeping it
> that way even while nibbling off bits for other uses, was bad protocol design,
> but that's water under the bridge.)
> 
> I would prefer to stop wasting time on trying to hijack the flow label and
> instead finish the work on an NHC representation.
> 
> Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Sep 2014 10:02:00 +0200

On 17 Sep 2014, at 09:48, Pascal Thubert (pthubert) <[email-masked]> wrote:

> - 6MAN on whether we can avoid having to set and/or carry a field of randomized 20 bits in the LLN  

Laudable, and completely unrelated to the hijacking.
(Not on critical path, anyway.)

> then eventually rewrite it for LLN purpose

Don’t do that.

> - ROLL to decide whether to use a ROLL solution (based on FL is the only one on the table) or

The flow label is not ROLL’s, so there is nothing to do here.

> wait for 6lo to deliver

ROLL has waited long enough for consensus to build in 6man around the flow label hijacking.
Not happening.

> - 6Lo to decide whether and how to compress the RPL option (3 proposals on the table)

I think we are converging quickly here.

Summary:

I’m calling for all involved to stop muddying the water with the dead flow label hijacking proposal.
It is a distraction from the consensus that is being built around a 6lo solution, and it will never fly.

Grüße, Carsten

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 17 Sep 2014 12:11:28 +0200

On Wednesday, September 17, 2014, Carsten Bormann wrote:

> On 17 Sep 2014, at 09:48, Pascal Thubert (pthubert) <[email-masked]
> <javascript:;>> wrote:
>

Why not?

> The flow label is not ROLL’s, so there is nothing to do here.

If this WG decides that we want ROLL's solution decision then we may do
cross WGs discussions or cross areas (this in not done much in IETF because
still IETF is not flexible or ADs are not promoting that enough).

> I think we are converging quickly here.

I think we need to clarify that 3 proposals. So why you think we are doing
it quickly.

> solution, and it will never fly.

Why you think that it is dead? I don't think it expired yet. What do you
mean by consensus built around 6Lo solution, do you mean the 6Lo charter?
Why you think that it never fly?

I understood Martins proposal but did not understand your reply reasons.

 AB

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Sep 2014 13:04:59 +0200

> Why not?

RFC 6437 explains what flow labels are and how you can use them.

> If this WG decides that we want ROLL's solution decision then we may do cross WGs discussions or cross areas (this in not done much in IETF because still IETF is not flexible or ADs are not promoting that enough). 

There already was a common WGLC between ROLL and 6man.
Initially, there was some flexibility on the 6man side along the lines of “if you really have to do this”.
Once it was demonstrated that there is no actual need to hijack the flow label, the sentiment shifted.
I see little point in repeating this experiment.

> I think we need to clarify that 3 proposals. So why you think we are doing it quickly. 

Because the 6lo WG has a track record of getting things done quickly.
(Also, I’m only aware of a single active proposal, but maybe I haven’t been paying enough attention.)

> Why you think that it is dead? 

See above.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2014 08:29:03 +0000

Hello Carsten and Martin;

One thing we need to be very clear on is the way LOWPAN_NHC works in 6282. That's very different from the dispatch type for instance.

You have a sequence on 1's followed by a 0. The number of 1's tell you what the LOWPAN_NHC type is. The bits after the first 0 are used for the specific use of that NHC.

With three 1's (first 0 at position 3, that is the fourth bit) the NHC an enumeration if classical NHCs, used to enable the compression of whatever comes after (eg UDP) without saving anything on that particular header.
With four 1's (first 0 at position 4) the NHC is UDP. We picked it because we could compress UDP with 3 bits in the LOWPAN_NHC.
Which leaves us with 6 possibilities for the first 0 at positions 0, 1, 2, 5, 6 and 7.

I picked one position 1, because we need 3 bits for RPL, one bit for the proposed compression format, and then one bit for the NH flag.
Because we need to kept the headers bytes-aligned, using a different encoding would probably lead us to one more octet overall, which would be very bad news for a 6lo based solution.

That would leave us with 5 more positions for the future out of  a total 8 at the beginning of times.

With this clearly in mind, would you suggest a different compression format?

Pascal

> Sent: mardi 16 septembre 2014 22:59
> Cc: Tisch; Martin Turon; [email-masked]
> Subject: Re: [6lo] Comparison of 6lo-rpl drafts
> 
> Hi Pascal,
> 
> (As with my draft, some additional text is needed to discuss how a hbh
> header that contains a RPL option beside other hbh option(s) is to be
> handled.)
> 
> Honestly, I'm not so hot about the verbiage in Section 1/2 of the draft.
> If we could get a draft that just contains the parts that need consensus, I
> could mark draft-bormann-6lo-rpl-mesh-01.txt as replaced-by that updated
> version, removing some of the current confusion about the way forward on
> this.
> 
> Using up 1/4 of the RFC 6282 NHC space for the RPL hbh option strikes me as
> expensive, even if we only have used ~ 1/8 of that space yet (GHC will need ~
> another 1/16).
> (I think this is the essence of Martin's comment, too.) If we want to work
> further on this draft, we should look for ways moving this down to, say, 1/8,
> without unduly increasing complexity.
> E.g., we could get rid of the forwarding-error bit, as that applies to storing
> mode only (we could use one additional NHC code, followed by the rest of
> the NHC code, to indicate a forwarding-error if people really think storing
> mode needs to be kept alive).
> 
> Note that we'll need another chunk of the NHC space to compress RFC 6554,
> so the total usage for RPL will be even higher.  (I tried to initiate the
> discussion for this with my question whether we need to stick with the
> reversible "segments left" model of RFC 6554 or can discard addresses that
> have been traversed.  If nobody has an opinion on this, I might want to go
> ahead and propose something.)
> 
> Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2014 08:40:37 +0000

Typo below, please read:

> I picked position 1, because we need 3 bits for RPL, TWO bitS for the

> proposed compression format, and then one bit for the NH flag.

Proposed rpl-nhc:

            0   1   2   3   4   5   6   7

          +---+---+---+---+---+---+---+---+

          | 1 | 0 | I | K | O | R | F |NH |

          +---+---+---+---+---+---+---+---+

Classical 6lowpan-nhc:

            0   1   2   3   4   5   6   7

          +---+---+---+---+---+---+---+---+

          | 1 | 1 | 1 | 0 |    EID    |NH |

          +---+---+---+---+---+---+---+---+

Classical udp-nhc:
            0   1   2   3   4   5   6   7
          +---+---+---+---+---+---+---+---+
          | 1 | 1 | 1 | 1 | 0 | C |   P   |
          +---+---+---+---+---+---+---+---+

Cheers,

Pascal

> From: Pascal Thubert (pthubert)

> Sent: jeudi 18 septembre 2014 10:27

> To: 'Carsten Bormann'; Martin Turon

> Subject: RE: [6lo] Comparison of 6lo-rpl drafts

> One thing we need to be very clear on is the way LOWPAN_NHC works in

> 6282. That's very different from the dispatch type for instance.

> You have a sequence on 1's followed by a 0. The number of 1's tell you what

> the LOWPAN_NHC type is. The bits after the first 0 are used for the specific

> use of that NHC.

> With three 1's (first 0 at position 3, that is the fourth bit) the NHC an

> enumeration if classical NHCs, used to enable the compression of whatever

> comes after (eg UDP) without saving anything on that particular header.

> With four 1's (first 0 at position 4) the NHC is UDP. We picked it because we

> could compress UDP with 3 bits in the LOWPAN_NHC.

> Which leaves us with 6 possibilities for the first 0 at positions 0, 1, 2, 5, 6 and

> 7.

> I picked one position 1, because we need 3 bits for RPL, one bit for the

> proposed compression format, and then one bit for the NH flag.

> Because we need to kept the headers bytes-aligned, using a different

> encoding would probably lead us to one more octet overall, which would be

> very bad news for a 6lo based solution.

> That would leave us with 5 more positions for the future out of  a total 8 at

> the beginning of times.

> > Cc: Tisch; Martin Turon; [email-masked]<mailto:[email-masked]>

> > If we could get a draft that just contains the parts that need

> > consensus, I could mark draft-bormann-6lo-rpl-mesh-01.txt as

> > replaced-by that updated version, removing some of the current

> > confusion about the way forward on this.

> > Using up 1/4 of the RFC 6282 NHC space for the RPL hbh option strikes

> > me as expensive, even if we only have used ~ 1/8 of that space yet

> > (GHC will need ~ another 1/16).

> > (I think this is the essence of Martin's comment, too.) If we want to

> > work further on this draft, we should look for ways moving this down

> > to, say, 1/8, without unduly increasing complexity.

> > E.g., we could get rid of the forwarding-error bit, as that applies to

> > storing mode only (we could use one additional NHC code, followed by

> > the rest of the NHC code, to indicate a forwarding-error if people

> > really think storing mode needs to be kept alive).

> > Note that we'll need another chunk of the NHC space to compress RFC

> > 6554, so the total usage for RPL will be even higher.  (I tried to

> > initiate the discussion for this with my question whether we need to

> > stick with the reversible "segments left" model of RFC 6554 or can

> > discard addresses that have been traversed.  If nobody has an opinion

> > on this, I might want to go ahead and propose something.)

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Sep 2014 13:11:28 +0200

> You have a sequence on 1's followed by a 0. The number of 1's tell you what the LOWPAN_NHC type is. The bits after the first 0 are used for the specific use of that NHC.

While this is a nice way of allocating the NHC bytes, we don’t *have* to play it that way, and it becomes more and more difficult to allocate the 256 code positions this way.

Also, RFC 6282 already uses 1110EIDN for the six different extension headers it supports.

So, we could use:

            0   1   2   3   4   5   6   7
          +---+---+---+---+---+---+---+---+
          | 1 | 0 | 0 | I | K | O | R |NH |
          +---+---+---+---+---+---+---+---+

together with a separate code

            0   1   2   3   4   5   6   7
          +---+---+---+---+---+---+---+---+
          | 1 | 1 | 0 | 1 | 1 | 1 | 1 | 0 |
          +---+---+---+---+---+---+---+---+

that prefixes 100IKORN if the F bit is set.

I’m assuming here storing mode doesn’t really exist and we only have to play lip service to it, so together with the low probability of an F bit being set even in storing mode it is OK to use an additional byte for this case.

(If the R bit is rare enough, we could play the same trick for it and reduce code space consumption from 1/8 to 1/16.  I don’t know enough about the probability of R bits to say whether this is a good idea or not.)

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2014 11:44:03 +0000

Hello Carsten:

Though it seems to happen in real life I'm quite phobic to the idea that the format and length of a 6lo header may change at as the packet is forwarded.
The F bit denotes an error. Say you have an error on a frame that is exactly 127 bytes long, well, the whole process of the F bit cannot happen.

If your suggestion is based in the assumption that storing mode will not happen, well, that is not consistent with what I'm hearing. 
I'm hearing about new designs for which memory will not be a constraint, while saving on the frame size will always be, so the ratio of storing mode device may increase rapidly.

And yes, I agree that there is nothing that forces us to follow Jonathan's original design but here it happens to work, so I'm happy to continue.

What do others think?

Pascal

> Sent: jeudi 18 septembre 2014 13:11
> Cc: Martin Turon; [email-masked]; [email-masked]
> Subject: Re: [6tisch] [6lo] Comparison of 6lo-rpl drafts
> 
> > You have a sequence on 1's followed by a 0. The number of 1's tell you
> what the LOWPAN_NHC type is. The bits after the first 0 are used for the
> specific use of that NHC.
> 
> While this is a nice way of allocating the NHC bytes, we don't *have* to play
> it that way, and it becomes more and more difficult to allocate the 256 code
> positions this way.
> 
> I'm assuming here storing mode doesn't really exist and we only have to play
> lip service to it, so together with the low probability of an F bit being set
> even in storing mode it is OK to use an additional byte for this case.
> 
> (If the R bit is rare enough, we could play the same trick for it and reduce
> code space consumption from 1/8 to 1/16.  I don't know enough about the
> probability of R bits to say whether this is a good idea or not.)
> 
> Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Sep 2014 13:55:50 +0200

> Though it seems to happen in real life I'm quite phobic to the idea that the format and length of a 6lo header may change at as the packet is forwarded.

That happens all the time, e.g. when the HLIM field doesn’t fit and the hop limit needs to be carried in line, when the router no longer has congruence between MAC layer and IP layer source address, etc.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2014 11:59:04 +0000

Yes, so I'm hearing as well.

I had that discussion with Richard recently.

My take is that if you are forwarding multihop, which you know as soon as the next hop is not the destination, then HLIM and addresses should not be compressed.
But that is discussed/specified nowhere, sadly...

Pascal

> Sent: jeudi 18 septembre 2014 13:56
> Cc: [email-masked]; Martin Turon; [email-masked]
> Subject: Re: [6lo] [6tisch] Comparison of 6lo-rpl drafts
> 
> > Though it seems to happen in real life I'm quite phobic to the idea that the
> format and length of a 6lo header may change at as the packet is forwarded.
> 
> That happens all the time, e.g. when the HLIM field doesn't fit and the hop
> limit needs to be carried in line, when the router no longer has congruence
> between MAC layer and IP layer source address, etc.
> 
> Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Sep 2014 14:05:58 +0200

> But that is discussed/specified nowhere, sadly...

My take is that a router must be prepared to do (adaptation layer) fragmentation on the fly.
An original sender can help against this by not filling up initial fragment packets to the max that it knows will be forwarded, but a single-fragment packet is always better than a multi-fragment one.
There is never a point in not doing compression when you could.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2014 12:35:25 +0000

This is exactly what IPv6 has learnt to avoid, Carsten.

Cheers,

Pascal

> Sent: jeudi 18 septembre 2014 14:06
> > My take is that if you are forwarding multihop, which you know as soon as
> the next hop is not the destination, then HLIM and addresses should not be
> compressed.
> An original sender can help against this by not filling up initial fragment
> packets to the max that it knows will be forwarded, but a single-fragment
> packet is always better than a multi-fragment one.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Sep 2014 14:43:55 +0200

> This is exactly what IPv6 has learnt to avoid, Carsten.

Yes, but we are talking about the adaptation layer here.

That always has to fragment on the fly.
Header compression is also well-known for generating interesting MTU issues.

We don’t have adaptation layer path MTU discovery (read the ALFI draft for one way of improving the situation here).
We also don’t have the large IPv6 MTU at the MAC layer.  So something has to give.

It’s not like we are designing RFC 6282 from scratch here, that already exists (and you are listed as a co-author!).

Grüße, Carsten

---

From: Martin Turon <[email-masked]>
Date: Thu, 18 Sep 2014 09:09:31 -0700

Hi Pascal,

On using NHC versus Flow Control for RPL routing options:
      - the current method in http://tools.ietf.org/html/rfc6553 uses next
header (hop-by-hop)
      - it seems natural for 6lo to compress this next header rather than
suddenly use the flow label
      - I understand the flow label is widely used for prototypes now, but
as a design progression it's somewhat random

On LOWPAN_NHC:
     - My interpretation of what is there now is that the "LOWPAN_NHC
dispatch" is the first four bits:
        - 0000-1101 unassigned
        - 1110 = IPv6 extension headers, including uncompressed next headers
        - 1111 = compressed UDP

                       0   1   2   3   4   5   6   7

                 Figure 13: IPv6 Extension Header Encoding

                       0   1   2   3   4   5   6   7

                      Figure 14: UDP Header Encoding

Your proposal is doing a huge land grab of this NHC dispatch
specifically for RPL.  It takes 16 possibilities, including one given
to a fairly popular transport layer named UDP, and turns the dispatch
into 1 of 4 possibilities.  It then allocates a quarter of that space
to a particular routing protocol named RPL, which albeit is popular on
6lo networks today, doesn't feel to me 4x more important than UDP.

draft-thubert-6lo-rpl-nhc-01

         0   1   2   3   4   5   6   7

My proposal is to add one more entry to the NHC for "compressed next
headers" which follows the with one sub-type for "compressed
hop-by-hop".  Then your rpl draft could drop in as the *first*
"compressed hop-by-hop".  At such a level, it is fine for rpl to take
1/4 of the space.  There is room in the top two "version" bits for 2
other important hop-by-hop and an "escape" sequence 11.

So the proposed LOWPAN_NHC "compressed next header" looks like this:

                       0   1   2   3   4   5   6   7
                     | 1 | 1 | 0 | 1 |    NHID       |

                 Figure 13: IPv6 Extension Header Encoding

   EID: IPv6 Compressed Next Header ID:

      0: 6LO compressed IPv6 Hop-by-Hop Options Header
         [including draft-thubert-6lo-rpl-nhc-01 and other
possibilities]                 + revisions to specify top two bits as
a sub-dispatch for general hop-by-hop compression

                + better would be to have 3 or 4 bits of sub-dispatch
if possible

      1 - 15: Reserved

I know it's "an extra byte", but 6lo has successfully designed with
future proofing and extensibility in mind, and I think it's important
that we steward it with that same leaning.  But this proposal
leverages all the work you've done on rpl-nhc.  It just drops in after
nhc=0xD0.

To clarify the revisions to your rpl-nhc draft, I'm suggesting it
become something more general, i.e. the
6lo-hop-by-hop-compression-draft, with the following first byte:

     00XXXXXX: (unassigned)

     01XXXXXX: (unassigned)
     10XXXXXX: Compressed RPL hop-by-hop
[draft-thubert-6lo-rpl-nhc-0]
     11XXXXXX: (unassigned)

Martin

On Thu, Sep 18, 2014 at 1:29 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> One thing we need to be very clear on is the way LOWPAN_NHC works in 6282.
> That's very different from the dispatch type for instance.
>
> With four 1's (first 0 at position 4) the NHC is UDP. We picked it because
> we could compress UDP with 3 bits in the LOWPAN_NHC.
> consensus, I
> work
> storing

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Sep 2014 16:47:47 +0000

Hello Martin:

My proposal does not steal from UDP; it is a misunderstanding on your part on how the encoding works, and I hope my recent mail clarified that (did you see it?).

I agree that my proposal uses an early position for the first 0 and thus consumes a large space in the NHC descriptor octet.

I went through the exact same question as you did, either introduce a new NHC as I chose to propose, or consume only a position in the 6LOWPAN_NHC at the expense of an additional octet in the frame, which, I understand, is your suggestion. Clearly the 2 options are on the table.

My inclination was to save that octet for the actual needs of the day, as opposed to save the NHC space for an hypothetical future.

My take is that in that future, PHYs with larger MTU will have generalized and consuming an octet will hurt less than it does now. Also, RPL may actually be quite successful in the IoT, in which case it is not entirely irrelevant to give it a lion’s share. Finally, the option I favored allows the overall cost to stay competitive with the flow label technique.

But that’s really a debate for the mailing list. I’m glad that you pointed it out, and even more glad if that’ll all that’s left to resolve : )

Cheers,

Pascal

From: Martin Turon [mailto:[email-masked]]
Sent: jeudi 18 septembre 2014 18:10
To: Pascal Thubert (pthubert)
Cc: Carsten Bormann; [email-masked]; [email-masked]
Subject: Re: [6lo] Comparison of 6lo-rpl drafts

Hi Pascal,

On using NHC versus Flow Control for RPL routing options:
      - the current method in http://tools.ietf.org/html/rfc6553 uses next header (hop-by-hop)
      - it seems natural for 6lo to compress this next header rather than suddenly use the flow label
      - I understand the flow label is widely used for prototypes now, but as a design progression it's somewhat random

On LOWPAN_NHC:
     - My interpretation of what is there now is that the "LOWPAN_NHC dispatch" is the first four bits:
        - 0000-1101 unassigned
        - 1110 = IPv6 extension headers, including uncompressed next headers
        - 1111 = compressed UDP

                       0   1   2   3   4   5   6   7

                       0   1   2   3   4   5   6   7

Your proposal is doing a huge land grab of this NHC dispatch specifically for RPL.  It takes 16 possibilities, including one given to a fairly popular transport layer named UDP, and turns the dispatch into 1 of 4 possibilities.  It then allocates a quarter of that space to a particular routing protocol named RPL, which albeit is popular on 6lo networks today, doesn't feel to me 4x more important than UDP.

         0   1   2   3   4   5   6   7

My proposal is to add one more entry to the NHC for "compressed next headers" which follows the with one sub-type for "compressed hop-by-hop".  Then your rpl draft could drop in as the *first* "compressed hop-by-hop".  At such a level, it is fine for rpl to take 1/4 of the space.  There is room in the top two "version" bits for 2 other important hop-by-hop and an "escape" sequence 11.

                       0   1   2   3   4   5   6   7

                     | 1 | 1 | 0 | 1 |    NHID       |

      0: 6LO compressed IPv6 Hop-by-Hop Options Header
         [including draft-thubert-6lo-rpl-nhc-01 and other possibilities]

                + revisions to specify top two bits as a sub-dispatch for general hop-by-hop compression

                + better would be to have 3 or 4 bits of sub-dispatch if possible

      1 - 15: Reserved

I know it's "an extra byte", but 6lo has successfully designed with future proofing and extensibility in mind, and I think it's important that we steward it with that same leaning.  But this proposal leverages all the work you've done on rpl-nhc.  It just drops in after nhc=0xD0.

To clarify the revisions to your rpl-nhc draft, I'm suggesting it become something more general, i.e. the 6lo-hop-by-hop-compression-draft, with the following first byte:

     00XXXXXX: (unassigned)

     01XXXXXX: (unassigned)

     10XXXXXX: Compressed RPL hop-by-hop            [draft-thubert-6lo-rpl-nhc-0]
     11XXXXXX: (unassigned)

Martin

On Thu, Sep 18, 2014 at 1:29 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Carsten and Martin;

Pascal

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Sep 2014 19:04:32 +0200

On 18 Sep 2014, at 18:09, Martin Turon <[email-masked]> wrote:

>  it's "an extra byte"

I agree with Pascal that we don’t need (or want) to spend that.

I still think that my F-bit proposal is good enough for reducing the bite out of the NHC space to something palatable.  (And it can be combined with the same approach for the R-bit if 1/8 is still too much.)

Grüße, Carsten

---

From: Martin Turon <[email-masked]>
Date: Fri, 19 Sep 2014 10:05:26 -0700

Hi Pascal,

I'm not claiming your proposal steals from UDP.  We do agree that the
proposal has RPL claiming a lion share of NHC.

I think the 127 byte frame will continue to exist for sometime, and that
future proofing should hold for these smaller frames.  A 6tsch slot for
example is designed around the 127 byte frame.  My vote would be to take
the hit on the extra byte.

Is there anyway to push 2 bits down into the RPL option payload so the NHC
claim is comparable to UDP?

Cheers,
Martin

On Fri, Sep 19, 2014 at 9:47 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Martin:
>
>
>
> My proposal does not steal from UDP; it is a misunderstanding on your part
> on how the encoding works, and I hope my recent mail clarified that (did
> you see it?).
>
>
>
> I agree that my proposal uses an early position for the first 0 and thus
> consumes a large space in the NHC descriptor octet.
>
>
>
> I went through the exact same question as you did, either introduce a new
> NHC as I chose to propose, or consume only a position in the 6LOWPAN_NHC at
> the expense of an additional octet in the frame, which, I understand, is
> your suggestion. Clearly the 2 options are on the table.
>
>
>
> My inclination was to save that octet for the actual needs of the day, as
> opposed to save the NHC space for an hypothetical future.
>
>
>
> My take is that in that future, PHYs with larger MTU will have generalized
> and consuming an octet will hurt less than it does now. Also, RPL may
> actually be quite successful in the IoT, in which case it is not entirely
> irrelevant to give it a lion’s share. Finally, the option I favored allows
> the overall cost to stay competitive with the flow label technique.
>
>
>
> But that’s really a debate for the mailing list. I’m glad that you pointed
> it out, and even more glad if that’ll all that’s left to resolve : )
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* Martin Turon [mailto:[email-masked]]
> *Sent:* jeudi 18 septembre 2014 18:10
> *To:* Pascal Thubert (pthubert)
> *Cc:* Carsten Bormann; [email-masked]; [email-masked]
>
> *Subject:* Re: [6lo] Comparison of 6lo-rpl drafts
>
>
>
> Hi Pascal,
>
>
>

---

From: Martin Turon <[email-masked]>
Date: Fri, 19 Sep 2014 10:21:28 -0700

Carsten,

A proposal that moves F+R bits to the RPL option payload would be great.

Let's remember that the NHC is the glue that links the entire header chain
together.  Let's not waste it, nor burn through it because bigger packets
are coming someday.

Martin

P.S. Your GHC proposal looks interesting.  I wonder how well it would
compress RFC 6553 headers.

On Fri, Sep 19, 2014 at 10:04 AM, Carsten Bormann <[email-masked]> wrote:

> I still think that my F-bit proposal is good enough for reducing the bite
> out of the NHC space to something palatable.  (And it can be combined with
> the same approach for the R-bit if 1/8 is still too much.)
>
> Grüße, Carsten
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Sep 2014 18:08:09 +0000

Hi Martin:

Then let us document clearly the 2 options and propose to the group.

If by pushing 2 bits you mean, like, having a short and a long version of the instanceID, well that’s doable, but extra code complexity that pushes the worst case to 5 octets anyway. I’m not inclined to do that, but here again, it is a matter of appreciation between solutions that work, so I do not have a strong position.

Cheers,

Pascal

Sent: vendredi 19 septembre 2014 19:05

Hi Pascal,

I'm not claiming your proposal steals from UDP.  We do agree that the proposal has RPL claiming a lion share of NHC.

I think the 127 byte frame will continue to exist for sometime, and that future proofing should hold for these smaller frames.  A 6tsch slot for example is designed around the 127 byte frame.  My vote would be to take the hit on the extra byte.

Is there anyway to push 2 bits down into the RPL option payload so the NHC claim is comparable to UDP?

Cheers,
Martin

On Fri, Sep 19, 2014 at 9:47 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Martin:

Cheers,

Pascal

From: Martin Turon [mailto:[email-masked]<mailto:[email-masked]>]
Sent: jeudi 18 septembre 2014 18:10
To: Pascal Thubert (pthubert)
Cc: Carsten Bormann; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Pascal,

On LOWPAN_NHC:

                       0   1   2   3   4   5   6   7

                       0   1   2   3   4   5   6   7

         0   1   2   3   4   5   6   7

                       0   1   2   3   4   5   6   7

                     | 1 | 1 | 0 | 1 |    NHID       |

      1 - 15: Reserved

     00XXXXXX: (unassigned)

     01XXXXXX: (unassigned)

Martin

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 20 Sep 2014 00:15:38 +0200

> A proposal that moves F+R bits to the RPL option payload would be great.  

I don’t think that can be done without
1) limiting the range of values for senderrank and instanceid, or
2) inventing a complicated variable-length encoding for them.
That’s why I went for escape codes, working from the assumption F (and maybe R) errors are relatively rare.
I don’t have any numbers for this, though.

> P.S. Your GHC proposal looks interesting.  

Thank you.

> I wonder how well it would compress RFC 6553 headers.

Not much: There just isn’t that much intra-packet redundancy that GHC could compress away (and GHC is stateless, so it can’t exploit the flow redundancy).  There is a limited amount of static info (first 4-6 bytes) that could have been put into the static dictionary or even implied by the NHC value that would need to be reserved for this.  I think it is better to do a (set of) NHC values specifically for this without invoking the more general GHC mechanics.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Sep 2014 14:27:31 -0400

> I see little point in repeating this experiment.

The 6man WG chairs have not confirmed the conclusion of Ines and I, and we
did not observe wuch a "shift".    One 6man co-chair is on paternity leave,
so perhaps we will still hear from them.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-