Subject: Re: [Roll] using the flow label instead of hop by hop

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 20 Oct 2012 08:19:37 +0000

Phil;

There is indeed lot of pressure for this in terms of header sizes and energy consumption in the *real world*.
And there is no hack in the proposed solution.
Simply we believe more in practical engineering and ML discussions than we trust in crystal balls. 

Cheers,

Pascal

-----Original Message-----
From: Philip Levis [mailto:[email-masked]] 
Sent: vendredi 19 octobre 2012 21:46
To: Owen Kirby
Cc: Pascal Thubert (pthubert); [email-masked]
Subject: Re: [Roll] using the flow label instead of hop by hop

I realize there's a lot of pressure for this in terms of header sizes, but this seems like exactly the kind of engineering hack/optimization that has painful long-term implications. Such as the Internet of Things prevents the flow label from ever being used effectively.

Phil

On Oct 19, 2012, at 11:59 AM, Owen Kirby wrote:

> Pascal,
> 
> I'm not entirely convinced that using the flow label like this is a good idea. Using the flow labels to carry the RPL HbH information works on the premise that packets being routed through the RPL domain wouldn't otherwise use the flow label. This assumption might be correct in a network of homogenous nodes with no external prefixes (eg: appendix A.5), but there may still be cases where packets being routed through the RPL domain might want to set the flow label. If this draft were to go forward, I would have some questions:
> 
> When a  forwarding node receives a packet with the flow label set, how does it determine whether the flow label contains an identifier of the 5-tuple, or it contains the RPL HbH information? To get it wrong would interfere with the forwarding behavior and lead to interoperability issues.
> 
> When packets are received from an external prefix, how does the ingress router handle the flow label? Would it destroy the original label, leave the original label in tact, or use IPv6-in-IPv6 encapsulation to preserve the label (ie: the inner header contains the original flow label, and the outer header contains the HbH information)?
> 
> How would the DODAG root rebuild the flow label from the 5-tuple if it encounters packets that have been fragmented at the IPv6 layer? The primary use of the flow label is so that routers don't have to reassemble IPv6 fragments when forwarding to determine the 5-tuple (which is a challenging thing for a router to do).
> 
> Cheers,
> Owen
> 
> On 18/10/2012 9:43 AM, Pascal Thubert (pthubert) wrote:
>> Hi
>>  
>> When I started this draft, we had a series of chats with Brian Carpenter and apparently reached a gentleman agreement that it was doable within the RPL domain to use the flow label and avoid the Hop by Hop option.
>>  
>> I published http://tools.ietf.org/html/draft-thubert-roll-flow-label-01 based on that discussion but did not get news from the group since then.
>>  
>> This technique has a number of advantages, in particular -it saves 
>> extra bytes for the RPL option and the HbH header.
>> -it also avoids the prescribed tunneling within the RPL domain for packets from the outside.
>> - it has an optimized compression with 6LoWPAN.
>>  
>> Is there interest in the group to continue? If so I'd be glad to have some discussion time at the next meeting.
>>  
>> Cheers,
>>  
>>  
>> 
>> Pascal Thubert
>> IPv6 Engineering
>> 
>> [email-masked]
>> Phone :+33 497 23 26 34
>> Mobile :+33 619 98 29 85
>> 
>> 
>> Cisco Systems
>> Village d'Entreprises Green Side bat. T3 400, Avenue Roumanille
>> 06410 Biot - Sophia Antipolis
>> France
>> 
>> Cisco.com
>> 
>> <Mail Attachment.jpeg>
>> 
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>> This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.
>>  
>>  
>> 
>> 
>> _______________________________________________
>> Roll mailing list
>> 
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Sat, 20 Oct 2012 06:50:14 -0700

> There is indeed lot of pressure for this in terms of header sizes and energy consumption in the *real world*.

I'm personally concerned about header sizes and energy consumption in The Matrix. Because I don't live in the real world. Oh, wait, sorry, I do. Can you walk me through the quantitative reasoning that a few bytes of header will increase energy consumption? It the belief that it will lead to sub-packet fragmentation in some non-amortized sense? Generally speaking, in low power wireless networks, energy consumption is dominated by idle listening and communication latency/interval support, not the length of packets. Of course there is a spectrum of low power approaches and their point on that spectrum. Are you thinking of one in particular?

Could implementers who are encountering this pressure comment? I'm a sucker for and easily swayed by quantitative data as well as first-hand rather than second-hand reports.

> Simply we believe more in practical engineering and ML discussions than we trust in crystal balls. 

*coughs politely* I believe in very practical engineering that considers long term consequences. Solving a problem a certain way now might cause significant problems in the future. I agree this is a tradeoff -- in my personal opinion, nothing more, the tradeoff on this one is 100% clear.

Phil

------

Philip Levis
President, Kumu Networks
Associate Professor, Stanford University
http://csl.stanford.edu/~pal

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 20 Oct 2012 20:37:07 +0100

Speaking as an individual and without an implementation...

Isn't this MPLS? 
Hasn't the routing area looked at the idea of using the IPv6 flow label for
labelled forwarding more than once in the past?
Hasn't the conclusion always been that you could do it, but you would have to be
sure that you were not overloading the field?
And hasn't the resulting discussion led to a debate on the value of label stacks
and the impracticality of label stacks using the flow label?

Cheers,
Adrian

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip
> Levis
> Sent: 20 October 2012 14:50
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]
> I'm personally concerned about header sizes and energy consumption in The
> Matrix. Because I don't live in the real world. Oh, wait, sorry, I do. Can you
walk
> me through the quantitative reasoning that a few bytes of header will increase
> energy consumption? It the belief that it will lead to sub-packet
fragmentation in
> some non-amortized sense? Generally speaking, in low power wireless
> networks, energy consumption is dominated by idle listening and communication
> latency/interval support, not the length of packets. Of course there is a
spectrum
> of low power approaches and their point on that spectrum. Are you thinking of
> one in particular?
> 
> Could implementers who are encountering this pressure comment? I'm a sucker
> for and easily swayed by quantitative data as well as first-hand rather than
> second-hand reports.
> 
> *coughs politely* I believe in very practical engineering that considers long
term
> consequences. Solving a problem a certain way now might cause significant
> problems in the future. I agree this is a tradeoff -- in my personal opinion,
nothing
> more, the tradeoff on this one is 100% clear.
> 
> Phil
> 
> ------
> 
> Philip Levis
> President, Kumu Networks

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 20 Oct 2012 21:29:37 +0000

Adrian,

This draft is not mpls. This draft is about carrying the RPL info (rank, instance, flags) in the flow label as opposed to the HbH which incurs additional header + eventually tunneling.
My other draft on fragment forwarding has a lot more to do with label switching since the first fragment lays a label that the other fragments follow. But then we are not using the flow label but a 6LoWPAN datagram identifier tag.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: samedi 20 octobre 2012 21:37
To: [email-masked]
Subject: Re: [Roll] using the flow label instead of hop by hop

Isn't this MPLS? 
Hasn't the routing area looked at the idea of using the IPv6 flow label for labelled forwarding more than once in the past?
Hasn't the conclusion always been that you could do it, but you would have to be sure that you were not overloading the field?
And hasn't the resulting discussion led to a debate on the value of label stacks and the impracticality of label stacks using the flow label?

Cheers,
Adrian

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Philip Levis
> > There is indeed lot of pressure for this in terms of header sizes 
> > and energy
> consumption in the *real world*.
> 
> I'm personally concerned about header sizes and energy consumption in 
> The Matrix. Because I don't live in the real world. Oh, wait, sorry, I 
> do. Can you
walk
> me through the quantitative reasoning that a few bytes of header will 
> increase energy consumption? It the belief that it will lead to 
> sub-packet
fragmentation in
> networks, energy consumption is dominated by idle listening and 
> communication latency/interval support, not the length of packets. Of 
> course there is a
spectrum
> of low power approaches and their point on that spectrum. Are you 
> thinking of one in particular?
> 
> Could implementers who are encountering this pressure comment? I'm a 
> sucker for and easily swayed by quantitative data as well as 
> first-hand rather than second-hand reports.
> 
> > Simply we believe more in practical engineering and ML discussions 
> > than we
> trust in crystal balls.
> 
term
> consequences. Solving a problem a certain way now might cause 
> significant problems in the future. I agree this is a tradeoff -- in 
> my personal opinion,
nothing
> Associate Professor, Stanford University http://csl.stanford.edu/~pal

---

From: John E Drake <[email-masked]>
Date: Mon, 22 Oct 2012 19:15:25 +0000

Pascal,

So the information that you are carrying in the IPv6 label field has nothing to do with IPv6 labels?  So, why is this not an egregious hack?

Yours irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Pascal Thubert (pthubert)
> Sent: Saturday, October 20, 2012 2:30 PM
> To: [email-masked]; [email-masked]
> This draft is not mpls. This draft is about carrying the RPL info
> (rank, instance, flags) in the flow label as opposed to the HbH which
> incurs additional header + eventually tunneling.
> My other draft on fragment forwarding has a lot more to do with label
> switching since the first fragment lays a label that the other
> fragments follow. But then we are not using the flow label but a
> 6LoWPAN datagram identifier tag.
> 
> Cheers,
> 
> Pascal
> 
> Hasn't the routing area looked at the idea of using the IPv6 flow label
> for labelled forwarding more than once in the past?
> Hasn't the conclusion always been that you could do it, but you would
> have to be sure that you were not overloading the field?
> And hasn't the resulting discussion led to a debate on the value of
> label stacks and the impracticality of label stacks using the flow
> label?
> 
> Cheers,
> Adrian
>