Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 1 Aug 2014 10:50:15 +0200

Dear Phil, all,

I do not completely agree :)

Let's look at what IPHC does at the LBR when a flow label is elided and has
to be inflated to be forwarded to the IPv6 network, this standardized
behaviour is somehow interfering the end to end notion of the flow label as
the content is being populated at the border of the LLN. For me this is not
different than changing the scope of the flow label inside the LLN to
transport RPL information and resetting  it at the LBR once data moves
outside of the network considering that inside the LLN the flow label has
no meaning.

Looking into an article we wrote some time back, "A Realistic Energy
Consumption Model for TSCH Networks". published in IEEE Sensors

we know that the charge used by a mote (something similar to telosb) to
send 127bytes is around 69uC and to receive them is 72uC (considering the
optimal case where receiver has a guard time of 1ms and the network is
synchronized).  By using the flow label instead of the RPL extension header
we save 5bytes which give us a gain 2,71uC per data packet per hop when
sent and something similar when received (i.e ~5uC in total), this is a 8%
saving (accounting TX and RX side) considering that motes are always using
127bytes packets.

If we go to a more realistic case where motes send ~50bytes packets, the
charge needed to send/receive them is something around 27.5uC and being
able to save 5 bytes represents a 10% saving for the sender and 10% for the
receiver (~20% saving if we look it overall per hop).
If we use batteries that power the mote for 5 years, a 20% saving gives us
~1 more year which I think is pretty significant.

regards,
Xavi

2014-08-01 0:11 GMT+02:00 Philip Levis <[email-masked]>:

>
> On Jul 29, 2014, at 6:36 PM, Brian E Carpenter <
> [email-masked]> wrote:
>
> > On 30/07/2014 12:02, Philip Levis wrote:
> > ...
> >> "This specification suggests that energy-saving is another
> >> compelling reason for a violation to the aforementioned
> >> rule."
> >>
> >> makes the assumption that the energy saving is significant.
> >> Breaking the end-to-end nature of the flow label for some
> >> tiny saving seems like a mistake.
> >
> > I can't evaluate whether the energy saving is significant.
> > However, I don't have any deep faith in the e2e-ness of the
> > flow label. The reality (as RFC 6437 tries to recognise)
> > is that it's a mutable field, and is therefore untrustworthy
> > for e2e use. It has value for load balancing if all packets
> > of a given flow have the same label, whether the label is
> > set by the source or by a border device. For that reason,
> > I think the usage proposed in this draft is OK.
> >
> > However, I do agree that at least a hand-waving estimate of
> > the % energy saving would be useful.
> >
> >    Brian Carpenter
>
> *shrug* My thoughts are pretty simple. I'm sure you know all this (as one
> of the authors!) but I'll revisit for everyone else's sake. 6437 states
>
> "A forwarding node MUST either leave a non-zero flow label value unchanged
> or change it only for compelling operational security reasons as described
> in Section 6.1."
>
> So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and
> should say so explicitly), or there should be an explicit update to 6437.
> In fact, the current draft is misleading and incorrect. It says
>
> "but the RFC also indicates a violation to the rule can be accepted for
> compelling reasons, and that security is a case justifying such a
> violation.  This specification suggests that energy-saving is another
> compelling    reason for a violation to the aforementioned rule."
>
> This is *not* what 6437 says. It says for compelling operational security
> reasons, not compelling reasons, of which one case is security.
>
> Having been researching, implementing, and deploying low-power protocols
> for over a decade, I've become exceedingly skeptical when someone proposes
> a protocol with energy as a motivation without quantifying it. For example,
> there are tons of protocols in the research literature which talk about
> using transmission power control to save energy (trading off range for
> power). But almost all of these papers ignore the fact that (unlike
> mobile/cellular systems, which the authors have been publishing in for
> years) RF is a tiny sliver of power in low-power networks. So reducing your
> transmission (RF) power by 99% only reduces your radio power by 50%.
> Generally a losing proposition. This is the same reason why power saving in
> WiFi involves synchronization on AP beacons and not adjusting transmit
> power. If someone doesn't quantify the potential benefit based on real
> hardware and protocols, then it could be based on mistaken assumptions.
>
> I mean, it doesn't take much here. Start with a working low-power RPL
> network. Send packets with sizes following a reasonable distribution based
> on an actual application. In one experiment send just those packets. In
> another add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation.
> Measure the energy cost.
>
> And, generally speaking, if you can't demonstrate the problem very easily,
> then perhaps it isn't a real problem at all.
>
> All that being said, I think using the flow label in this way is a good
> idea, and definitely valuable. But as it is now, doing so violates 6437,
> and so the assumptions implementers make when reading 6437. I think the bar
> for doing so should be high, higher than vague suggestions and hand waving
> which might not be correct.
>
> Phil
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 1 Aug 2014 13:23:44 +0200

On 01 Aug 2014, at 10:50, Xavier Vilajosana <[email-masked]> wrote:

> 
> Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN. 

No.  With IPHC, the flow label has always been there, it just was transmitted in a very compressed form.

I think the visceral reaction that most of us have in using the flow label as a mesh routing header is that this blurs the layer boundaries.  So much for O, R, F, and rank.  Putting the VLAN (“instance ID”) into the packet is a significantly larger change, because it essentially extends the IP service interface by a VLAN ID.  We normally try to hide IDs of this kind below IP.

Now, I’m not saying any of this new architecture is wrong.  I just think what we need to do is discuss this as the architectural change that it is, not as a simple optimization.  (The need for some kind of optimization of IP-in-IP mesh routing for small-packet IoT applications is pretty obvious to me.)

The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason”.  Cynically, one could say this is proper payback for designing this field without a compelling purpose and no protocol evolution story attached to it.  So the evolution just eats it.  Teachable moment.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Aug 2014 12:44:41 +0000

Hello Phil:

The end-to-end principle will not break in pieces if we reuse the flow label field within the LLN. 

FYI, it will break nothing since there is no assumption in the Internet that the flow label will be carried unchanged. Consistently, there is no native way to secure the flow label to make sure it was not tempered with (IOW it is not protected by ULP checksums, IPSec AH or ESP transport mode). 

The last call at 6MAN is where I expect problems with the use of the flow label field in this draft to be pointed at. I'm happy to report that there was no trace of bigotry there, all the contrary. 6MAN will confirm whether this draft conforms the spirit of the existing RFCs and so far I gathered, from all but you, that it does.

About SDOs: To be very clear, ISA100.11a made a clear condition to acceptance of 6LoWPAN that we compress the UDP checksum - 2 bytes. And we made that happen.
As the standard is now considering what new work may be taken in, RPL will not be considered if we waste those 5 bytes, simple as that. Sorry that you missed the ROLL meeting, but Pat Kinney was very clear on that both as vice chair of 802.15,  and as chair of ISA100.11a where he "fought over every byte". " Both hats say that this is what we need this".

We'll also note that each additional octet in a frame is an increased chance of loss and retry. This is an argument that I hear frequently at IEEE and the people there as well as at ISA100 are very sensitive to frame size in general.

The distribution of the frame size and the cost of security depend on the application and the app layer. With high levels of security, if the distribution includes NLPDU around 80-90 octets then the extra bytes will cause fragmentation, which will add all sorts of new problems to the picture.

The benefits are quite clear, both on actual numbers (thanks Xavi!) and on the political arena where such a waste of bytes is just not defendable.

Please reconsider where you are placing your efforts and what you are trying to achieve...

Pascal

> -----Original Message-----
> From: Philip Levis [mailto:[email-masked]]
> Sent: vendredi 1 août 2014 00:11
> To: Brian E Carpenter
> Cc: Ines Robles; Brian Haberman; [email-masked]; Michael Richardson; roll;
> Bob Hinden; Ole Troan (otroan); Pascal Thubert (pthubert); Adrian Farrel
> Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
> 
> 
> On Jul 29, 2014, at 6:36 PM, Brian E Carpenter
> <[email-masked]> wrote:
> 
> >> "This specification suggests that energy-saving is another compelling
> >> reason for a violation to the aforementioned rule."
> >>
> >> Breaking the end-to-end nature of the flow label for some tiny saving
> >> seems like a mistake.
> >
> > However, I don't have any deep faith in the e2e-ness of the flow
> > label. The reality (as RFC 6437 tries to recognise) is that it's a
> > mutable field, and is therefore untrustworthy for e2e use. It has
> > value for load balancing if all packets of a given flow have the same
> > label, whether the label is set by the source or by a border device.
> > For that reason, I think the usage proposed in this draft is OK.
> >
> > However, I do agree that at least a hand-waving estimate of the %
> > energy saving would be useful.
> >
> >    Brian Carpenter
> 
> *shrug* My thoughts are pretty simple. I'm sure you know all this (as one of
> the authors!) but I'll revisit for everyone else's sake. 6437 states
> 
> "A forwarding node MUST either leave a non-zero flow label value
> unchanged or change it only for compelling operational security reasons as
> described in Section 6.1."
> 
> should say so explicitly), or there should be an explicit update to 6437. In
> fact, the current draft is misleading and incorrect. It says
> 
> compelling reasons, and that security is a case justifying such a violation.
> This specification suggests that energy-saving is another compelling    reason
> for a violation to the aforementioned rule."
> 
> for over a decade, I've become exceedingly skeptical when someone
> proposes a protocol with energy as a motivation without quantifying it. For
> example, there are tons of protocols in the research literature which talk
> about using transmission power control to save energy (trading off range for
> All that being said, I think using the flow label in this way is a good idea, and
> definitely valuable. But as it is now, doing so violates 6437, and so the
> assumptions implementers make when reading 6437. I think the bar for
> doing so should be high, higher than vague suggestions and hand waving

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Aug 2014 12:56:40 +0000

> the content is being populated at the border of the LLN.
> 

My take is that you are both providing angles on a same thing. It does not make sense for a LLN node to waste compute power and bandwidth to get a random through that is of use only in the core of the internet, should the packet ever get there. So the flow label is effectively zero - or something locally significant in specific standards, which is not design to serve the purpose of load balancing in the core. So in either case, we need the root to 'inflate' the zero flow label, or replace it by something that fits the core of the Internet. That behavior was not specified so far and it should be. This document is covering this particular gap.

Cheers,

Pascal

> From: ipv6 [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: vendredi 1 août 2014 13:24
> To: Xavier Vilajosana
> Cc: roll; [email-masked]
> the content is being populated at the border of the LLN.
> 
> I think the visceral reaction that most of us have in using the flow label as a
> mesh routing header is that this blurs the layer boundaries.  So much for O,
> R, F, and rank.  Putting the VLAN ("instance ID") into the packet is a
> significantly larger change, because it essentially extends the IP service
> interface by a VLAN ID.  We normally try to hide IDs of this kind below IP.
> 
> Now, I'm not saying any of this new architecture is wrong.  I just think what
> we need to do is discuss this as the architectural change that it is, not as a
> simple optimization.  (The need for some kind of optimization of IP-in-IP
> mesh routing for small-packet IoT applications is pretty obvious to me.)
> 
> The other story is that we are retracting RFC 6437 and turning the flow label
> into the "field you may trample on in your lower layers if you have a good
> reason".  Cynically, one could say this is proper payback for designing this
> field without a compelling purpose and no protocol evolution story attached
> to it.  So the evolution just eats it.  Teachable moment.
> 
> Grüße, Carsten
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Aug 2014 13:25:06 +0000

> mesh routing for small-packet IoT applications is pretty obvious to me.)
I agree, Carsten.

An angle is that we allow for localized usage of the flow label as opposed to end-to-end.

Another is that we allow for different semantics within a local domain, as long as the packet that leaves the local domain fits the requirements in RFC 6437.

As you point out, it is worth noting that we include information about flow isolation and rules by which a flow will be routed, which is akin to Multi-Topology Routing though MTR is based on TOS bits.

It would be good to design an architecture that encompasses such capabilities.

We'll note that ISA100.11a is shipping with a flow label that contains an index to a state (so-called a contract) that is installed on the nodes on the way and by and large extends the notion of PHB on a per flow basis.

Cheers,

Pascal

---

From: Philip Levis <[email-masked]>
Date: Fri, 1 Aug 2014 09:21:46 -0700

On Aug 1, 2014, at 5:44 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

> The last call at 6MAN is where I expect problems with the use of the flow label field in this draft to be pointed at. I'm happy to report that there was no trace of bigotry there, all the contrary. 6MAN will confirm whether this draft conforms the spirit of the existing RFCs and so far I gathered, from all but you, that it does

Pascal, I don't think this is a question of spirit or anything. I mean, I'll repeat, 6437 states

"A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1."

If the point is that experience and use and the spirit of the flow label has changed from this MUST, then we should explicitly state so. I'm not arguing that the above prescription is right; but it's what's written. What worries me is the idea of directly contradicting the text of a prior RFC (the one explicitly on flow labels, no less), without correspondingly obsoleting that RFC. This isn't a SHOULD. It's a MUST!

I've always thought that using the flow label in this way within an LLN is a good idea. The problem is that you can't do so without violating a MUST in the RFC that specifies how flow labels are used. It sounds like the letter of that document doesn't match the spirit of it -- so let's fix the letter, so it says what was intended! Why is there such recalcitrance to do so? Or provide any quantitative basis for the claims of battery power? You've been proposing this for nearly 4 years now...

I personally see two reasonable ways forward:

1) (As Carsten mentioned) Update 6437 to embrace these new and valuable uses of the flow label.

2) Provide evidence that using the flow label in this way would provide significant enough gains that violating a MUST in the RFC specifying the flow label is worth it.

It seems like you're advocating a third:

3) Violate a MUST in the RFC specifying how the flow label is used without any evidence that the actual energy savings are significant.

As for what I'm trying to achieve, that's pretty simple. I think it's a terrible mistake for a standards body as important as the IETF to rely on the spirit of the standard rather than the letter of the standard, especially when they contradict. If you are one of the hundreds of thousands of network engineers and software developers who work in the Internet, you can't know that a bunch of people in a meeting decided that the spirit of a specification differs from its text. All you have to go on is the text. When the founder of the next YouTube or Instagram or Google or Nicira takes my class and I ask them to write their code to follow an RFC (which I currently do), what should I tell them MUST means?

Phil

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Aug 2014 07:58:39 +1200

On 01/08/2014 23:23, Carsten Bormann wrote:
...
> The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason”.  Cynically, one could say this is p…

RFC 6437 co-author hat on (but only speaking for myself, of course):

My opinion is that the draft doesn't retract RFC 6437. As I already said,
6437 attempts to recognise the reality that middleboxes can mess with the
flow label, and to set conditions for that messing such that remote systems
can still use it for load balancing. Since it's unprotected by checksum or
crypto, there is a strict limit to how much it can be trusted anyway. As
the RFC says:

   There is no way to verify whether a flow label has been modified en
   route or whether it belongs to a uniform distribution.  Therefore, no
   Internet-wide mechanism can depend mathematically on unmodified and
   uniformly distributed flow labels; they have a "best effort" quality.
   Implementers should be aware that the flow label is an unprotected
   field that could have been accidentally or intentionally changed en
   route (see Section 6).

It is true that the RFC also says

   A forwarding node
   MUST either leave a non-zero flow label value unchanged or change it
   only for compelling operational security reasons...

There is a case for arguing that flow-label-for-rpl should carry the
legend "Updates: 6437 (if approved)" because it adds another exception
to this sentence. There is also a case for arguing that flow-label-for-rpl
is a stateful mechanism, out of scope for RFC 6437 according to
Section 4 of that RFC.

Either way, I don't see a problem.

Regards

   Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Aug 2014 20:27:40 +0000

Phil,

Though I attended the discussions and have a clear reading of this work I'll certainly defer to Brian on whether there is a violation or not. 

OTOH you need to understand that there is no need for a bis to update a MUST in an RFC. We recognize the imperfection in our work and are always ready to revise and amend after due consideration.

This process takes is another RFC and best judgement from the original group that the new text is indeed valuable and not breaking the original objectives.

We are going through that process.

Pascal

> Le 1 août 2014 à 18:50, "Philip Levis" <[email-masked]> a écrit :
>

---

From: Philip Levis <[email-masked]>
Date: Fri, 1 Aug 2014 23:02:17 -0700

> We are going through that process.

If the proposal is to have an Updates: 6437 (such that someone looking up 6437 will see a forward reference and know there's an update), I'm all in favor! That seems entirely reasonable. In that way, as I've always said, I think using the flow label is an excellent solution. I just also think doing so is significant in the context of 6437 and so should correctly acknowledge so. Someone reading 6437 should be able to easily learn there's another exception. It seems like an Updates: would do that well. 

That being said, I don't think the energy claims in the current document will hold up to much experimental scrutiny or actual network measurements. Xavier's back-of-the-envelope calculations don't include preambles, slot padding, or idle listening. TSCH is nice in that it has much lower idle listening costs than ad-hoc algorithms, but they are far from zero. Reducing overhead is valuable due to the corresponding increase in MSS and reduced memory pressure: the energy argument is a red herring.

Phil

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Aug 2014 15:08:55 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > OTOH you need to understand that there is no need for a bis to update a
    > MUST in an RFC. We recognize the imperfection in our work and are
    > always ready to revise and amend after due consideration.

Perhaps this document UPDATES 6437 then?

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Aug 2014 15:23:13 -0400

Philip Levis <[email-masked]> wrote:
    > The paper is very helpful, thanks! Can you comment on what is a typical
    > idle slot configuration in a TiSCH network? Can you provide some
    > insight on what fraction of energy is spent in data communication
    > versus control and idle listening?

Here is a recent post with some real numbers:
  https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY
it concerns diet-ESP, but the numbers are correct.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 2 Aug 2014 20:48:49 +0000

That sounds right, Michael, though slightly on the overkill side.  And this is consistent with what Brian suggested. This can be added during the rfc editor process I expect?

Pascal

> Le 2 août 2014 à 21:09, "Michael Richardson" <[email-masked]> a écrit :
> 
>

---

From: Ralph Droms <[email-masked]>
Date: Sat, 2 Aug 2014 16:56:36 -0400

> On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)" <[email-masked]> wrote:
> 
> That sounds right, Michael,

I agree that "updates 6437" is a right thing to do.

> though slightly on the overkill side.

I disagree that it is overkill.  In my opinion, draft-thubert-6man-flow-label-for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an appropriate action.

>  And this is consistent with what Brian suggested. This can be added during the rfc editor process I expect?

It should be added as soon as possible, certainly before it goes to the IESG.  In my opinion, the change might warrant a new or extended WGLC; that action is up to the chairs, of course.

- Ralph

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Sat, 2 Aug 2014 14:41:12 -0700

> it concerns diet-ESP, but the numbers are correct.

Michael,

I'm confused on what this email message is supposed to be providing: the energy cost of sending a bit? That's pretty simple to calculate. The tradeoff between CPU and network is also very well known, going back to Pottie's "Every bit transmitted brings a sensor node one moment closer to death." If you look at the behavior of most micro controller based devices, the MCU is insignificant -- and 95% of its energy is spent handling interrupts (per-byte, over an SPI bus) for the radio. Yes, unless you're doing something quite silly, the CPU cost of compression is almost always absolutely worth the benefit in terms of reduced transmission energy.

My question related to the fraction of radio energy in TSCH that is consumed by data transmission/reception versus everything else (idle listening, guard periods, control frames, etc.

To give you a data point -- early low-power link layers continually transmitted a packet (or wakeup frame) until receiving an acknowledgement from the intended receiver. Receivers periodically wake up, listen if there's energy on the channel, and if so, stay awake for 2 packet times (in case they woke up just after the preamble of a packet). If there's no coordination between receiver and sender, this means a sender must send on average for 1/2 of a wakeup interval to deliver a packet. E.g., 0.5s. Clearly in such a protocol a few extra bytes doesn't matter in terms of energy. Of course, TSCH is much, much better than this, I only mention this protocol as a simple explanatory example -- but what's the actual number?

Phil

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 2 Aug 2014 20:36:44 -0700

Phil,

There are two parts in answering your question. Let me describe both, I
will then justify why the answer is "it depends".

*a single slot*

Let's consider for starters only a single TSCH slot: mote A sends a packet
to mote B, which replies with an ACK. This timeslot is depicted below
(borrowed from [1])

      /------------------- Time Slot duration --------------------/
      |                                        /tsShortGT/        |
      |            |                              | | |           |
      |------------+-----------------+--------------+------+------|
   TX |            |    TX-Packet    |              |RX Ack|      |
      |------------+-----------------+--------------+------+------|
      |/tsTxOffset/|                 |              |      |      |
      |            |                 |              |      |      |
      |------------+-----------------+--------------+------+------|
   RX |         |  |  | RX-Packet    |              |TX Ack|      |
      |---------+--+--+--------------+--------------+------+------|
      |         |  |  |              |              |      |      |
      |        /tsLongGT/            |/TsTxAckDelay/|      |      |
     Start                                                       End
      of                                                          of
     Slot                                                        Slot

Let's assume that the IEEE802.15.4 frame is 127B long, i.e. full length.
Let's assume, finally, that you are using the default 10ms timeslot
template from the IEEE802.15.4e-2012 standard [2] (Table 52e), no CCA. This
is the radio-on time on both A and B:

   - mote A
      - transmitting the data packet: 4256us
      - listening for ACK during the guard time (i.e. idle listening): 200us
      - receiving the ACK (~15B long): 480us
   - mote B:
      - listening for data during the guard time (i.e. idle listening):
      1000us
      - receiving data: 4256us
      - transmitting the ACK: 480us

>From an energy point of view, you also need to account for the time is
takes to switch the radio on/off and for the possible energy consumed
between the data and ack, in case the radio is kept in a state allowing it
to TX/RX fast. Good embedded engineers will reduce this overhead through
firmware and hardware wizardry.

Considering only time, the radio on-time budget can hence be cut into:

   - total: 10672us
   - transmission of data: 8512us (~80%)
   - desynchronization overhead (i.e. idle listening during guard time):
   1200us (~10%)
   - ACK overhead: 960us (~10%)

>From these numbers, you see that the actual data transmission accounts for
~80% of the radio-on time budget.

Of course, this timeslot template is the default one. If you are very good
at keeping synchronized, you might be able to shorten the guard times and
reduce the desynchronization overhead.

*full network*

Now the fun part.

In a TSCH network, the communication schedule indicates to every mote what
to do: transmit, listen or sleep. You can tune the TSCH communication
schedule any way you want. In fact, the 6TiSCH WG was created to define
mechanisms for centralized and distributed managements of this schedule.

Your goal should be to match the amount of bandwidth in your schedule (i.e.
the cells used for transmission and reception) to what is needed by the
network. If every cell you schedule is used, the single slot results from
above carry over to a full network. If, however, you schedule has too many
cells, some might be unused. In that case, the transmitter will keep its
radio off (i.e. consume no energy), while the receiver will have to listen
for a full guard time, or 2ms when using the default timeslot template.

So there you go: it depends. In the best possible case, the portion of
radio on-time spent of exchanging actual useful data can be very high
(80%+), but it's easy to mess things up, resulting in a large number of
over-provisioned cells.

For a (hopefully clear) overview of IEEE802.15.4e TSCH, take a look at
http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01.

Thomas

[1] http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02
[2] http://standards.ieee.org/getieee802/download/802.15.4e-2012.pdf

On Sat, Aug 2, 2014 at 2:41 PM, Philip Levis <[email-masked]> wrote:

> I'm confused on what this email message is supposed to be providing: the
> energy cost of sending a bit? That's pretty simple to calculate. The
> tradeoff between CPU and network is also very well known, going back to
> Pottie's "Every bit transmitted brings a sensor node one moment closer to
> death." If you look at the behavior of most micro controller based devices,
> the MCU is insignificant -- and 95% of its energy is spent handling
> interrupts (per-byte, over an SPI bus) for the radio. Yes, unless you're
> doing something quite silly, the CPU cost of compression is almost always
> absolutely worth the benefit in terms of reduced transmission energy.
>
> My question related to the fraction of radio energy in TSCH that is
> consumed by data transmission/reception versus everything else (idle
> listening, guard periods, control frames, etc.
>
> To give you a data point -- early low-power link layers continually
> transmitted a packet (or wakeup frame) until receiving an acknowledgement
> from the intended receiver. Receivers periodically wake up, listen if
> there's energy on the channel, and if so, stay awake for 2 packet times (in
> case they woke up just after the preamble of a packet). If there's no
> coordination between receiver and sender, this means a sender must send on
> average for 1/2 of a wakeup interval to deliver a packet. E.g., 0.5s.
> Clearly in such a protocol a few extra bytes doesn't matter in terms of
> energy. Of course, TSCH is much, much better than this, I only mention this
> protocol as a simple explanatory example -- but what's the actual number?
>
> Phil
>
>
>
>

---

From: Philip Levis <[email-masked]>
Date: Sun, 3 Aug 2014 10:28:39 -0700

Thomas,

This is great, thank you! Precise, technical statements. What I conclude from your text (correct me if I'm wrong):

1) If 802.15.4e uses maximum sized frames (127 bytes), the data communication time (reception or transmission) within a transmit slot is 80% of the total radio-on time. I appreciate that you separate the costs of the two sides (e.g., idle listening guard period on receive).

2) Following Xavier's analysis, using 127-byte frames means the RPL option increases data communication time by 4%. This means, from 1), that it will increase energy consumption by ~3.5%. Or, supposing his 8% number is correct (I still don't understand how he reached it), the energy consumption is increased by ~6.5%.

3) For smaller frames (e.g., the 50 bytes Xavier suggested), the idle listening on the receiver takes a larger fraction of the radio-on time, so his 10% number is too high.

4) None of these calculations consider the control overhead or, as you point out, inefficiencies in slot assignment. E.g., if you have a low-bandwidth, low-delay network, then you will allocate slots (for low latency) that you do not use (low bandwidth). For networks that are perfectly tuned, as you suggest, you can approach the transmission slot gains in 1) and 2). But they do not consider the costs and time of beacons or management time slots. Or radio wakeup overhead (dead time): my understanding is that on modern chips this is about 300us? I think your ACK timing considers RX/TX turnaround time. So in that way, 1) and 2) represent the absolute *best* savings this might give you. 

So my conclusion from this data is that, in the absolute best case -- assuming the radio is all of the system energy, you have a perfectly tuned TSCH schedule, etc., etc., using the flow label will save <10%, and often on the order of 5%. For simpler, less efficient and tuned MAC layers, the savings will be less.

5% or 10% isn't huge, but it is significant and valuable. I've just been a bit confused as to why this proposal has been trotted around for 4 years and yet no-one had yet even done this simple calculation, so WG members could make an informed engineering decision. IMO, a 5-10% savings in already highly tuned networks is above the bar and worth it. In most networks, the savings will be much less, but the benefits of reduced memory pressure and larger application payloads without fragmentation are more than sufficient motivation and justification of the value of the approach.

Phil

On Aug 2, 2014, at 8:36 PM, Thomas Watteyne <[email-masked]> wrote:

> Phil,
> 
> There are two parts in answering your question. Let me describe both, I will then justify why the answer is "it depends".
> 
> a single slot
> 
> Let's consider for starters only a single TSCH slot: mote A sends a packet to mote B, which replies with an ACK. This timeslot is depicted below (borrowed from [1])
> 
> 
> Let's assume that the IEEE802.15.4 frame is 127B long, i.e. full length. Let's assume, finally, that you are using the default 10ms timeslot template from the IEEE802.15.4e-2012 standard [2] (Table 52e), no CCA. This is the radio-on time on both A and B:
> 	• mote A
> 		• transmitting the data packet: 4256us
> 		• listening for ACK during the guard time (i.e. idle listening): 200us
> 		• receiving the ACK (~15B long): 480us
> 	• mote B:
> 		• listening for data during the guard time (i.e. idle listening): 1000us
> 		• receiving data: 4256us
> 		• transmitting the ACK: 480us
> From an energy point of view, you also need to account for the time is takes to switch the radio on/off and for the possible energy consumed between the data and ack, in case the radio is kept in a state allowing it to TX/RX fast. Good embedded engineers will reduce this overhead through firmware and hardware wizardry.
> 
> 	• total: 10672us
> 	• transmission of data: 8512us (~80%)
> 	• desynchronization overhead (i.e. idle listening during guard time): 1200us (~10%)
> 	• ACK overhead: 960us (~10%)
> From these numbers, you see that the actual data transmission accounts for ~80% of the radio-on time budget.
> 
> Of course, this timeslot template is the default one. If you are very good at keeping synchronized, you might be able to shorten the guard times and reduce the desynchronization overhead.
> 
> full network
> 
> Now the fun part.
> 
> In a TSCH network, the communication schedule indicates to every mote what to do: transmit, listen or sleep. You can tune the TSCH communication schedule any way you want. In fact, the 6TiSCH WG was created to define mechanisms for centralized and distributed managements of this schedule.
> 
> Your goal should be to match the amount of bandwidth in your schedule (i.e. the cells used for transmission and reception) to what is needed by the network. If every cell you schedule is used, the single slot results from above carry over to a full network. If, however, you schedule has too many cells, some might be unused. In that case, the transmitter will keep its radio off (i.e. consume no energy), while the receiver will have to listen for a full guard time, or 2ms when using the default timeslot template.
> 
> So there you go: it depends. In the best possible case, the portion of radio on-time spent of exchanging actual useful data can be very high (80%+), but it's easy to mess things up, resulting in a large number of over-provisioned cells.
> 
> For a (hopefully clear) overview of IEEE802.15.4e TSCH, take a look at http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01.
> 
> Thomas
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Aug 2014 11:50:57 +0200

> On 01 Aug 2014, at 21:58 , Brian E Carpenter <[email-masked]> wrote:
> 

I see the principles in these two documents as mutually exclusive:
RFC6437: middleboxes can mess with the flow label
-flow-label-for-rpl: networks uses flow label field as an immutable protocol field

you can't both use the flow label as an immutable protocol field and have middleboxes rewriting it.

cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Aug 2014 10:02:27 -0400

Philip Levis <[email-masked]> wrote:
    > 5% or 10% isn't huge, but it is significant and valuable. I've just
    > been a bit confused as to why this proposal has been trotted around for
    > 4 years and yet no-one had yet even done this simple calculation, so WG
    > members could make an informed engineering decision. IMO, a 5-10%

my opinion:

1) the exact calculation was hard to really do until 6tisch made it clearer
   what the duty cycle was going to be.

2) it took awhile to come back to figuring out how to deal with the flow
   label issue.

3) it is now clear exactly how close many of our packets are to the 127 byte
   limit, and how much the HbH header hurts if it is the reason we go into
   two fraglets.

4) we had other things to worry about!

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Aug 2014 10:15:15 -0400

On 01 Aug 2014, at 21:58 , Brian E Carpenter <[email-masked]> wrote:
    >> A forwarding node MUST either leave a non-zero flow label value
    >> unchanged or change it only for compelling operational security
    >> reasons...
    >>
    >> to this sentence. There is also a case for arguing that
    >> flow-label-for-rpl is a stateful mechanism, out of scope for RFC 6437
    >> according to Section 4 of that RFC.
    >>

Ole Troan <[email-masked]> wrote:
    > RFC6437: middleboxes can mess with the flow label -flow-label-for-rpl:
    > networks uses flow label field as an immutable protocol field

    > have middleboxes rewriting it.

This is my take.
Case 1:  packet is within the LLN.  No issue; the sender sets the flow label,
     and we know (by design) that there aren't any (non-RPL) middle boxes
     that need to rewrite it.

Case 2: the packet has to leave the LLN, travel across the Internet, and
     enter another LLN.
     Here the arguments about the LLN being a kind of virtual host from
     the document are relevant.  The flow label, when it crosses the
     Internet, would be immutable.  Prior to this document, the flow label
     would have been compressed out, been zero, and the DODAG root ought to
     have set it in some consistent fashion anyway.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Aug 2014 15:41:55 +0000

Exactly;

It can be argued that the LLN is a single something that is a more complex form of the classical host-router link from the L3 perspective.
RFC6437 understands that the host can leave the flow label to all zeroes and allows the first router to set it in a recommended fashion. 
The draft pushes that role to the RPL root that is effectively the gateway from the LLN onto the Internet.
Upon the WLLC discussion I have added " Updates: 6437 (if approved) " and posted an update with no other change in the text.

Cheers,

Pascal

> From: ipv6 [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: lundi 4 août 2014 16:15
> To: Ole Troan
> Cc: roll; 6man WG

---

From: Philip Levis <[email-masked]>
Date: Mon, 4 Aug 2014 11:24:39 -0700

Michael,

1) doesn't depend on 6tisch, it's based on 15.4e timing, and could have been calculated for any other low power link layer. Years ago.

2) The proposal isn't substantively different -- in terms of bytes sent/saved -- from the first version of the proposal suggested in 2010.

3) The analysis so far hasn't even touched this issue.

4) The entire introduction/motivation for the proposal is saving energy! But no-one thought it important enough to actually estimate how much energy it would save (in a best case, typical case) before a last call?

Here's my worry -- the tradeoffs of low-power networks are very different than the kinds of networks the IETF typically deals with. It'll lead to protocol decisions a bit different than always-on networks. But that doesn't mean it should be used as a blanket justification or motivation. Otherwise it's just smoke and mirrors (energy is critical! battery is critical! we therefore need less CPU-intensive compression schemes! here's a new one. we need less CPU-intensive cryptographic schemes! here's a new one.). If energy is so important, and this would be such a big savings, then why the recalcitrance to estimate it?  It doesn't help my confidence in the engineering when some of the back-of-the-envelope analyses (Xavier's) have basic arithmetic errors that seem incognizant of how to measure energy. 

Phil

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 10 Aug 2014 18:29:01 +0200

So far, we have mainly discussed the need for an optimization (it seems we now agree there is a need) and the interaction between the normative components of RFC 6437 and those of the draft at hand.

I’d now like to bring up a different question:

Is this the right approach?

I have written up what appears to be a more natural approach in the strawman draft:
http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00

Why are we doing the flow-label thing and not the more natural thing?

[ ] because the flow label hack works on packets that leave the 6lo networks.
    • but do we really need to optimize this on the non-6lo networks?
[ ] because the flow label hack has been around for a while and is now cast in stone.
    • is it?
[ ] because there is a flaw with the way this has been integrated into the 6lo framework.
    • ______ (fill in the flaw)
[ ] because ______ (fill in the reason)

Inquiring minds want to know.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 10 Aug 2014 17:05:34 +0000

Hi Carsten

I think you jumped too quickly on my suggestion at 6lo.

It makes a lot of sense to work on a 6lo routing dispatch and in particular enable the compression of all RPL artifacts. 

It will take some time to figure out what goes in there but my suggestion at 6lo includes routing header compression, RPL option, but also source destination if we decide to route fragments. 

I hope this happens and I'll see with Laurent if we use a respin of his draft or I start a new one.

This work will be beneficial in the long run, but doubly fails to address the issues at stake here:

- the draft proposes to update the rules in 6437 with stateful and with domain scoped operations. This is used by the draft itself but also by published and deployed standards that came up before 6437 (eg ISA100.11a) and we are now acknowledging and legalizing a de facto situation.

- it will take a year or 2 at best to agree on the new routing dispatch and its operation. We need an improvement now. And btw we cannot necessarily assume 6lo together with RPL, I know of at least one RPL implementation that does not use that compression. 

Finally, Using a dispatch for the RPL option alone seems like a waste, but that is a discussion for 6lo. I'll publish there when I'm back from vacations.
 
Cheers,

Pascal

> Le 10 août 2014 à 18:29, "Carsten Bormann" <[email-masked]> a écrit :
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 10 Aug 2014 21:07:04 +0200

> - it will take a year or 2 at best to agree on the new routing dispatch and its operation. We need an improvement now. And btw we cannot necessarily assume 6lo together with RPL, I know of at least…

I don’t understand why we can’t do the saner equivalent of the flow label hack now and come up with a source routing header (which is not covered by the flow label hack) later.

Please tell us more about how ISA100.11a uses the flow label; that is information that has been lacking from the discussion so far.

Grüße, Carsten

---

From: Philip Levis <[email-masked]>
Date: Fri, 15 Aug 2014 17:33:35 -0700

On Aug 15, 2014, at 12:49 PM, Ray Hunter <[email-masked]> wrote:

> After reading the draft it seems to me that what is being attempted is
> 1) to add some stuff to the IPv6 header that is RPL domain specific
> 2) to reduce the overall packet length to reduce active radio time and thus save energy
> by
> 3) overloading an existing well-defined and used IPv6 header field
> 
> My simple logic tells me that
> 1) could be best solved at an architecture level via an extension header http://tools.ietf.org/html/rfc2460#page-11 + http://tools.ietf.org/html/rfc7045
> 2) could be best solved at an architecture level via IP header compression http://tools.ietf.org/html/rfc2507.html with or without additional tweaks
> and that overloading an opaque field in 3) by incorporating values with low entropy (as per the RPL flow label) gives additional security risks to http://tools.ietf.org/html/rfc7098
> 
> So what's wrong with my simple logic?

1) There is an extension header already; the problem is that it can introduce a significant (ballpark estimates are, in well engineered networks, up to 5-10%) cost. The proposal is to replace the extension header with using the flow label.

2) There'a already significant IP header compression in the cases we're talking about.

Phil

---

From: Ray Hunter <[email-masked]>
Date: Fri, 15 Aug 2014 21:49:21 +0200

Carsten Bormann wrote:
> On 01 Aug 2014, at 10:50, Xavier Vilajosana<[email-masked]>  wrote:
>
+1

Apologies for tardy response (holidays)

After reading the draft it seems to me that what is being attempted is
1) to add some stuff to the IPv6 header that is RPL domain specific
2) to reduce the overall packet length to reduce active radio time and 
thus save energy
by
3) overloading an existing well-defined and used IPv6 header field

My simple logic tells me that
1) could be best solved at an architecture level via an extension header 
http://tools.ietf.org/html/rfc2460#page-11 + 
http://tools.ietf.org/html/rfc7045
2) could be best solved at an architecture level via IP header 
compression http://tools.ietf.org/html/rfc2507.html with or without 
additional tweaks
and that overloading an opaque field in 3) by incorporating values with 
low entropy (as per the RPL flow label) gives additional security risks 
to http://tools.ietf.org/html/rfc7098

"But if we consider the whole RPL domain as a large virtual host from 
the standpoint of the rest of the Internet" would suggest to me that the 
cost of stripping out the additional IPv6 hop by hop extension header at 
the edge of the domain is a bogus argument, as you'll anyway have to 
provide some adaption and security at the root of each RPL domain to 
detect and bounce spoofed RPL Information from entering, or private RPL 
Information leaking out of each domain. Whether this domain-specificRPL 
Information is encoded in an explicit hop by hop option or an overloaded 
flow label would seem largely irrelevant to that operation at the RPL 
root (especially since the RPL root anyway has to be a high power node 
to be able communicate with the rest of the Internet).

IMHO If you overload the flow label you're looking at creating an 
incompatible walled garden, with competing IETF standards that are 
mutually exclusive.

-- 
Regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Sat, 16 Aug 2014 08:49:18 +0200

> Philip Levis <mailto:[email-masked]>
> 16 August 2014 02:33
>
> 1) There is an extension header already; the problem is that it can 
> introduce a significant (ballpark estimates are, in well engineered 
> networks, up to 5-10%) cost. The proposal is to replace the extension 
> header with using the flow label.
>

I'm sympathetic to the needs of low power devices.

However, to be clear, we are reengineering a standards track document 
that is around 2 years old (http://tools.ietf.org/html/rfc6553), and 
which works technically, and we are proposing an additional encoding of 
exactly the same information to achieve theoretical efficiency gains 
that are still only rough estimates?

Where's the experimental proof that this will really pay off in 
increased battery life?

You write "replace". Will 6553 now be deprecated?

If not we'll have:

6553 to carry RPL information as an option header.

draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a 
flow label

flow label information used to select patch and load balancing in 
multi-path networks. e.g.
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203
http://tools.ietf.org/html/rfc6438
http://tools.ietf.org/html/rfc7098

I do not see that these applications for this one field are mutually 
compatible, and worse still, the only way to decode the semantics of the 
overloaded field is by applying some unknown external context ("within 
RPL domain"/ "on the Internet").

The hidden "cost" here is that we will have 3 different overlapping 
solutions = code bloat and potentially a lot of additional processing to 
locate the correct information and then process it, which is also a hit 
on energy efficiency.

IMHO the bar should be pretty high for accepting this proposal, as it is 
not actually solving a tangible issue.

Also my prediction of the next request for field overloading will be:
My ISP only delegates one /64 with PD
I have multiple links in my Homenet
All my media is EUI48 based. No one really uses EUI64.
I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for 
routing in Homenet by encoding a (V)LAN ID in it.
It's OK though. Homenet is a walled garden and I'll rewrite the field at 
the exit so no one will ever know.

As an alternative: if this information is really RPL specific, why not 
just add the RPL Information as a tag to the front of the packet e.g. 
via an MPLS label?

MPLS labels are only 4 octets, and are designed to be very efficient and 
fast.
You can easily strip them at egress, and munge it/set it on ingress.
It's clear where an MPLS domain ends and starts: no chance of RPL 
information leaking onto the Internet, or entering from the Internet.
The MPLS label also transports the 20 bits of information you need.
MPLS labels are at a clear fixed position in the packet and are easy and 
efficient to parse.
You could also then nest RPL domains if you ever wanted to do that.
It's also extensible, as you can push more labels on the stack in the 
future if you ever want to extend the RPL Information transported, 
whereas the flow label is a single fixed field.
It does not require any new standard, except maybe an informational RFC 
on how to encode the RPL Information into MPLS labels.
And it doesn't overload anything.

regards,

> Ray Hunter <mailto:[email-masked]>
> 15 August 2014 21:49
>
>
>
> +1
>
> 1) could be best solved at an architecture level via an extension 
> header http://tools.ietf.org/html/rfc2460#page-11 + 
> and that overloading an opaque field in 3) by incorporating values 
> with low entropy (as per the RPL flow label) gives additional security 
> risks to http://tools.ietf.org/html/rfc7098
>
> the standpoint of the rest of the Internet" would suggest to me that 
> the cost of stripping out the additional IPv6 hop by hop extension 
> header at the edge of the domain is a bogus argument, as you'll anyway 
> have to provide some adaption and security at the root of each RPL 
> domain to detect and bounce spoofed RPL Information from entering, or 
> private RPL Information leaking out of each domain. Whether this 
> domain-specificRPL Information is encoded in an explicit hop by hop 
> option or an overloaded flow label would seem largely irrelevant to 
> that operation at the RPL root (especially since the RPL root anyway 
> has to be a high power node to be able communicate with the rest of 
> the Internet).
>
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Aug 2014 07:55:05 +1200

Ray,

> RPL domain"/ "on the Internet").

No, I don't see a problem there. The boundary of a RPL domain is
very well defined and flow-label-for-rpl clearly specifies that
outside that boundary, RFC 6437 applies (which enables RFC 6438
and 7098).

> not actually solving a tangible issue.

Whether ROLL wants to endorse alternative methods within RPL
domains is not a 6man question.
> the exit so no one will ever know.

Nice strawman, but why is it relevant? There's no need to rewrite
the bits, BTW. As RFC 7136 says:
"However, the method of generating IIDs for specific link types MAY
define some local significance for certain bits... the whole IID value
MUST be viewed as an opaque bit string by third parties, except possibly
in the local context."

   Brian

---

From: Ray Hunter <[email-masked]>
Date: Sun, 17 Aug 2014 11:52:21 +0200

> Brian E Carpenter <mailto:[email-masked]>
> 16 August 2014 21:55
> Ray,
>
>>> Philip Levis<mailto:[email-masked]>
>>> 16 August 2014 02:33
>>>
But inside an RPL domain, you cannot use any RFC's that reference the 
flow label as per 6437, because all of the entropy has gone.

And what happened to our end to end architecture?

I just do not like the concept of parsing a packet, and then having to 
determine the semantics of the contents of a particular field based on a 
"domain" that is not carried anywhere in the packet.
e.g. think about decoding offline captures
>>> Ray Hunter<mailto:[email-masked]>
>>> 15 August 2014 21:49
>>>
>>>
>>>
>>> +1
>>>

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Aug 2014 07:58:17 +1200

> flow label as per 6437, because all of the entropy has gone.

Correct. But isn't that a trade-off that might be reasonable in
the low-power lossy environment? (That's not intended as a rhetorical
question - I just don't have enough knowledge of that environment
to answer it.)

> And what happened to our end to end architecture?

There are various views of what e2e means, but I still like the
phrase "certain required end-to-end functions can only be performed
correctly by the end-systems themselves". Load balancing and adaptive
routing are not actually e2e functions in that sense.

> "domain" that is not carried anywhere in the packet.

I see the objection, but we've been doing it for years; diffserv does
it by definition.

   Brian

---

From: Ray Hunter <[email-masked]>
Date: Mon, 18 Aug 2014 19:26:54 +0200

> 17 August 2014 21:58
>>> Brian E Carpenter<mailto:[email-masked]>
>>> 16 August 2014 21:55
>>> Ray,
>>>
I would prefer to avoid making the trade off if we don't have to. Who 
knows what future application will use the flow label?

I'm no RPL expert, but 
http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01 seems more 
elegant and avoids all of this discussion.
> I see the objection, but we've been doing it for years; diffserv does
Agreed. But that is also largely being overtaken by MPLS Traffic 
Engineering, precisely so you can have an extensible label stack, or 
nest QoS domains, whilst still easily accessing the required label info 
at all points along the forwarding path.

-- 
Regards,
RayH

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Aug 2014 17:20:16 -0400

I just want to point out that the RPL Instance ID isn't used for routing
like the MPLS label. RPL nodes still do longest prefix match routing
on IPv6 destination address.

If you had to make an analogy to other technology, it's more like a VLAN
tag being used to pick a virtual router/routing table.

> I would prefer to avoid making the trade off if we don't have to. Who knows
> what future application will use the flow label?

Yes, my response is: "hi, we are the future. Do you mind if we use that
     thing you reserved for us?"

> I'm no RPL expert, but
> http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01 seems more elegant
> and avoids all of this discussion.

6lo-rpl-mesh is certainly merits discussion.

---

From: Robert Cragie <[email-masked]>
Date: Wed, 20 Aug 2014 15:48:22 +0100

I have been following this discussion with interest and here is my quick 
take on it:

* Flow label seems a fairly abstract concept and it doesn't seem 
unreasonable to use the space it occupies within a specific domain like 
RPL. What is proposed in draft-thubert-6man-flow-label-for-rpl-03 
doesn't seem consistent with the principle of what a "flow" is though as 
it changes hop-by-hop, which is clearly not the intended purpose for a 
flow label field. However, as others have pointed out, it is still a 
mutable field as far as AH is concerned and therefore that does not 
preclude the use as specified in 
draft-thubert-6man-flow-label-for-rpl-03. It is also clear that the flow 
label has to be reset at the edge of the domain anyway.
* Route-over in a mesh network changes everything. The use of the RPL 
option in RFC6553 does indeed seem reasonable but the IP-in-IP 
construction then complicates matters considerably.
* What Carsten proposes in draft-bormann-6lo-rpl-mesh-01 makes the most 
sense to me as putting it at "layer 2.5" is the logical place to put 
this sort of information due to it being hop-by-hop

So in summary, I have no real objection to what is proposed in 
draft-thubert-6man-flow-label-for-rpl-03 but I think Carsten's approach 
is better.

Robert