Re: [Roll] [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation

["6man issue tracker" <[e-mail]>]

#6: draft-thubert-6man-flow-label-for-rpl-03  Updates: 6437 (if approved)  -
add section with explanation


Comment (by [e-mail]):

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08763.html


 From: Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> 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

 ----
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08764.html



 From: Carsten Bormann <cabo at tzi.org> Date: Fri, 1 Aug 2014 13:23:44
 +0200

 On 01 Aug 2014, at 10:50, Xavier Vilajosana <xvilajosana at
 eecs.berkeley.edu> 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

 -------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08765.html



 From: Pascal Thubert (pthubert) <[e-mail]>  2014-08-01 15:44
 GMT+03:00


 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


 ----

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08766.html



 From: "Pascal Thubert (pthubert)" Date: Fri, 1 Aug 2014 12:56:40 +0000

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

 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

 ------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08767.html



 From: "Pascal Thubert (pthubert)"  Date: Fri, 1 Aug 2014 13:25:06 +0000

 > 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.)
 >
 >
 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

 ----------


 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08768.html



 From: Philip Levis <[e-mail]> Date: 2014-08-01 19:21 GMT+03:00

 On Aug 1, 2014, at 5:44 AM, Pascal Thubert (pthubert) <[e-mail]>
 wrote:
 >
 > 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

 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

 --------------
 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08769.html



 From: Brian E Carpenter  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 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.

 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

 --------


 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08770.html



 From: Pascal Thubert (pthubert) <[e-mail]> Date: 2014-08-01
 23:27 GMT+03:00

 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


 -------

 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08772.html



 From: Philip Levis <[e-mail]> Date: 2014-08-02 9:02 GMT+03:00

 On Aug 1, 2014, at 1:27 PM, Pascal Thubert (pthubert) <[e-mail]>
 wrote:

 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

 -----

 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08774.html



 From: Michael Richardson <[e-mail]> Date: 2014-08-02 22:08
 GMT+03:00

 Pascal Thubert (pthubert) <[e-mail]> 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

 ------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08775.html



 From: Michael Richardson <[e-mail]> Date: 2014-08-02 22:23
 GMT+03:00

 Philip Levis <[e-mail]> 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.
 Michael Richardson
 -------------------


 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08776.html



 From: Pascal Thubert (pthubert) <[e-mail]> Date: 2014-08-02
 23:48 GMT+03:00

 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" <[e-mail]> a
 écrit :
 > Perhaps this document UPDATES 6437 then?

 -----------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08777.html

 From: Ralph Droms <[e-mail]> Date: 2014-08-02 23:56 GMT+03:00

 >On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)"
 <[e-mail]> 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


 --------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08778.html


 From: Philip Levis <[e-mail]> Date: 2014-08-03 0:41 GMT+03:00
 >
 > 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.

 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

 ------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08779.html

 From: Thomas Watteyne <[e-mail]> Date: 2014-08-03 6:36
 GMT+03:00

 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])

 (Please go to the source to see the graphic)

 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

 ----------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08780.html

 From: Philip Levis <[e-mail]> Date: 2014-08-03 20:28 GMT+03:00

 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

 --------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08781.html

 From: Ole Troan <otroan at employees.org> Date: Mon, 4 Aug 2014 11:50:57
 +0200

 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



 ----------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08782.html

 From: Michael Richardson <[e-mail]> Date: 2014-08-04 17:02
 GMT+03:00

 Philip Levis <[e-mail]> 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!


 Michael Richardson

 ---------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08783.html

 From: Michael Richardson Date: Mon, 04 Aug 2014 10:15:15 -0400

 Ole Troan <otroan at employees.org> 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.

 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.
 --
 Michael Richardson

 -------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08784.html

 From: "Pascal Thubert (pthubert)" 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

 -----------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08785.html

 From: Pascal Thubert (pthubert) <[e-mail]> Date: 2014-08-04
 21:01 GMT+03:00

 The change is now done, Ralph.

 The only difference between draft-thubert-6man-flow-label-for-rpl-03 and
 draft-thubert-6man-flow-label-for-rpl-04 is

 Updates: 6437 (if approved)

 Cheers,

 Pascal

 ------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08786.html

 From: Ralph Droms <[e-mail]> Date: 2014-08-04 21:10 GMT+03:00

 I suggest adding a section to your doc that explains exactly what is being
 updated in RFC 6437.

 - Ralph

 --------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08787.html

 From: Philip Levis <[e-mail]> Date: 2014-08-04 21:23 GMT+03:00

 I agree. I think some of the text in 1.3 can be re-used for this purpose.

 Phil

 --------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08788.html

 From: Philip Levis <[e-mail]> Date: 2014-08-04 21:24 GMT+03:00

 On Aug 4, 2014, at 7:02 AM, Michael Richardson <[e-mail]>
 wrote:

 >

 >
 > 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!

 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

 -----------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08789.html

 From: Pascal Thubert (pthubert) <[e-mail]> Date: 2014-08-04
 21:52 GMT+03:00

 Hi Ralph:

 This is exactly section 3.

 The section provides a scope of applicability (the RPL domain) and the
 changes from RFC 6437 that become acceptable within that scope.

 Cheers,

 Pascal

 -------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08790.html

 From: Ralph Droms <rdroms.ietf at gmail.com>  Date: Mon, 4 Aug 2014
 15:44:10 -0400


 On Aug 4, 2014, at 2:52 PM 8/4/14, Pascal Thubert (pthubert)
 <[e-mail]> wrote:

 > Hi Ralph:
 >
 > This is exactly section 3.
 >
 > The section provides a scope of applicability (the RPL domain) and the
 changes from RFC 6437 that become acceptable within that scope.

 I disagree.  Section 3 explains how draft-thubert-6man-flow-label-for-rpl
 can be interpreted as following RFC 6437 rather than describing the
 specific ways in which it updates RFC 6437.

 For example, as Philip wrote:

 > "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.

 - Ralph


 -----------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08791.html

 From: Brian E Carpenter <[e-mail]> Date: 2014-08-04
 23:44 GMT+03:00

 Ralph,

 It also says that there may be stateful ways of using the flow label.
 It's almost a matter of taste whether the RPL usage is a change to
 the phrase that you quote, or a stateful usage within an RPL domain
 (reverting to stateless use when leaving RPL). I agree that the draft
 could usefully be explicit about this.

    Brian

 --------------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08793.html

 From: Philip Levis <[e-mail]> Date: 2014-08-05 3:18 GMT+03:00


 On Aug 4, 2014, at 1:44 PM, Brian E Carpenter
 <[e-mail]> wrote:

 > It also says that there may be stateful ways of using the flow label.
 > It's almost a matter of taste whether the RPL usage is a change to
 > the phrase that you quote, or a stateful usage within an RPL domain
 > (reverting to stateless use when leaving RPL). I agree that the draft
 > could usefully be explicit about this.

 I'm a bit confused -- the MUST statement is in Section 2, entitled "IPv6
 Flow Label Specification". There doesn't seem to be any text that suggests
 this restriction is dependent on stateless operation. My interpretation,
 based on the title and its placement in the document, is that the text in
 this section applies to any and all uses of the flow label. How am I
 reading this wrong? Should I be reading the final MUST ("… MUST choose
 labels that conform to Section 3 of this specification") in Section 4 to
 implicitly mean that Section 2 doesn't necessarily apply? Or is it
 optional for stateless as well?

 My (admittedly naive) reading is that Sections 3 and 4 related to how
 source nodes choose a flow label. (S2: "To enable Flow-Label-based
 classification, source nodes SHOULD assign each unrelated transport
 connection and application data stream to a new flow.")  This is distinct
 from what forwarding nodes do to flow labels, which Section 2 covers.

 Phil

 --------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08794.html

 From: Brian E Carpenter <[e-mail]> Date: 2014-08-05
 4:06 GMT+03:00

 Philip,

 I think you're right that it could have been worded more precisely.
 My personal mental model has always included something like the
 RPL application (i.e. a specific usage of the flow label within
 a closed domain) *and* generic stateless use by default, but I
 don't think that model has ever been the general consensus, so
 what is supposed to happen at the boundary between such a closed
 domain and the rest of the Internet has never been written down.

    Brian

 ---------------------------------------------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08795.html

 From: Pascal Thubert (pthubert) <[e-mail]> Date: 2014-08-05
 11:11 GMT+03:00

 I think I see what you are saying, Phil.

 I can split 1.3 to isolate the deviations to 6437.

 I also need to move the following text from section 3 in that new section

   This may seem contradictory with the IPv6
    Flow Label Specification [RFC6437] which stipulates that once it is
    set, the Flow Label is left unchanged; 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.

 Proposed update for that text:

    This specification updates the IPv6
    Flow Label Specification [RFC6437], which stipulates that once it is
    set, the Flow Label is left unchanged. [RFC6437] also indicates that
    a violation to the rule can be accepted for compelling reasons,
    but limit those compelling reasons to security related issues.  This
    specification indicates that energy-saving is another compelling
    reason that justifies a violation to the aforementioned rule.

 What do you think?

 Cheers,

 Pascal

 ------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08796.html

 From: Anand SVR <[e-mail]> Date: 2014-08-05 20:18 GMT+03:00

 Hi,

 The discussion has been very interesting, more so because it is bordering
 on the legality of the usage of the word MUST. I agree with Philip's take
 on this. But after reading the RFC, I got this impression that the RFC
 meant to be a facility or a feature with certain usage guidelines. The
 MUST usage is more to imply stronger than SHOULD so as to discourage
 people from modifying it. I suppose at the time of writing, the authors
 might not have foreseen that in some point in future the value can be
 changed for other reasons. Therefore the use of MUST MUST be taken with
 the right spirit it is meant to be taken rather than literally :)

 Anand

 ---------------------------------------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08797.html

 From: Philip Levis <[e-mail]> Date: 2014-08-06 7:57 GMT+03:00

 I totally agree that the document leaves the question open of whether
 there could be future uses. The use of the flow label in that way doesn't
 go against the spirit of the document and so we shouldn't reject the idea
 out of principle. But it does go against the letter of the document --
 hence the need for an Updates: or other explicit note that this is the
 case.

 Phil

 ------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08800.html

 From: Philip Levis <pal at cs.stanford.edu> Date: Thu, 7 Aug 2014 10:35:01
 -0700

 Seems reasonable to me, although a bit cumbersome. I'd suggest

   This document updates the IPv6
   Flow Label Specification [RFC6437], which stipulates that once the Flow
   Label is set, forwarding nodes do not update it unless there are
 compelling
   security reasons to do so. This document argues that saving energy in
 LLNs
   is another sufficiently compelling reason to modify the Flow Label.

 Phil

 ---------------------------------------------------------





 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08803.html

 From: Ralph Droms <[e-mail]> Date: 2014-08-08 23:19 GMT+03:00

 On Aug 5, 2014, at 4:11 AM 8/5/14, Pascal Thubert (pthubert)
 <[e-mail]> wrote:

 > I think I see what you are saying, Phil.
 >
 > I can split 1.3 to isolate the deviations to 6437.
 >
 > I also need to move the following text from section 3 in that new
 section
 >
 >  This may seem contradictory with the IPv6
 >   Flow Label Specification [RFC6437] which stipulates that once it is
 >   set, the Flow Label is left unchanged; 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.
 >
 > Proposed update for that text:
 >
 >   This specification updates the IPv6
 >   Flow Label Specification [RFC6437], which stipulates that once it is
 >   set, the Flow Label is left unchanged. [RFC6437] also indicates that
 >   a violation to the rule can be accepted for compelling reasons,
 >   but limit those compelling reasons to security related issues.  This
 >   specification indicates that energy-saving is another compelling
 >   reason that justifies a violation to the aforementioned rule.

 Well, I personally don't read the text in RFC 6437 as saying "a violation
 to the rule can be accepted for compelling reasons".  To avoid arguments
 with difficult individuals like me, you might take a more neutral
 approach:

 This document updates the following text from RFC 6437, "IPv6 Flow
 Label Specification":

 OLD:

    Once set to a non-zero value, the Flow Label is expected to be
    delivered unchanged to the destination node(s).  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.

 NEW:

    Once set to a non-zero value, the Flow Label is expected to be
    delivered unchanged to the destination node(s).  A forwarding node
    MUST either leave a non-zero flow label value unchanged or change
    it only for (1) compelling operational security reasons as
    described in Section 6.1 or (2) use as specified in RFC-to-be, "The
    IPv6 Flow Label within a RPL domain".

 - Ralph

 ----------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08804.html

 From: Brian E Carpenter <[e-mail]> Date: 2014-08-08
 23:36 GMT+03:00

 Ralph,

 I *really* don't think RFCs are algorithms to the point where we
 need to do this. I see no reason why flow-label-for-rpl can't simply
 declare itself an exception to this clause of RFC 6437.

    Brian

 --------------------------------------------------

-- 
-------------------------------------------------+-------------------------
 Reporter:  [e-mail]            |       Owner:
     Type:  defect                               |  [e-mail]
 Priority:  major                                |      Status:  new
Component:  draft-thubert-6man-flow-label-for-   |   Milestone:
  rpl                                            |     Version:
 Severity:  In WG Last Call                      |  Resolution:
 Keywords:                                       |
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/6#comment:1>
6man <http://tools.ietf.org/wg/6man/>