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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Owen:

I think we are back to the discussion with Brian (cc'ing Brian to make sure my account is faithful).
I think that we converged that the draft is actually doable, considering the LLN as one bug host from the perspective of the wider Internet.

With the proposal, the LLN gateway is in charge of setting the flow label towards the Internet and the flow label does not belong to the packet originator in the LLN, which, like any host in the Internet for the last 20 years, are wasting the precious bits.
So if an LLN originator sets the flow label it will be erased and recalculated if the LLN uses that draft. Can we justify that?

1) First thing first, the flow label is part of the IP header. Which is where you place stuff that you want examined by the router.
Anything farther down the packet will be a lot more trouble for the router. And app level communication does not belong here, whether it is a LLN app or any other app.

2) After 15 years of IPv6, the internet community finally found and standardized a usage for the label that basically adds burden to the hosts to serve the core but neiter sender nor receiver can use the value of the field for any practical usage.
For LLN devices that would mean ask a battery operated constrained node to do additional computation in case the packet goes in the powered Internet and needs load balancing. Do you know of any LLN device that would spend energy doing that?
It makes a lot more sense to push the burden to the power border router at the edge of the LLN in case the packet goes out the LLN towards the Internet.

3) The FL can only be compressed if it is NULL. This is the natural value for any constrained device, whether it aims at forwarding over RPL or not.
The burden of computing the tuple in the originator is not only on that node, but on all nodes in the LLN, and that would be whether the packet goes out to the Internet where the tuple can be used, or not.
HbH adds up to the waste, additional encap then adds up too. In a LLN that means wasting energy on every packet, with practical and measurable consequences in terms of battery life. In classical 15.4 that also means more fragmentation, and the consequences cascade.

The draft does not prevent an instance that needs the flow label for other usages to use the HbH. But is allows to control the damage when flow label is not used otherwise. Please see inline


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.

[] Does not. If the instance is configured for Flow Label, then the original value is lost. In the future, we could store it in a new HC option but so far the need as not emerged.


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

[] The only usage is in the core. When the FL comes in the LLN, the role is done, the FL would be ignored anyway.
I hoped we could convey something end to end here, like a hint for the instanceId, but failed so far.
So we are back to the BR selecting the instance based on the same heuristics as if the HbH is used.


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

[] Since the BR compute the FL, it uses the same heuristic for the first and all fragments. Mixing instanceID and IP addresses mostly. Or keeping only the instanceID when we want the latency+jitter to be homogeneous within an instance over the net. For LLN applications, the distribution of 5 tuples is a lot wider than necessary or even beneficial for the core,  and instanceID + IP provides a better granularity and more meaningful volumes.

Cheers,

Pascal

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

[e-mail]<mailto:[e-mail]>
Phone :[phone]
Mobile :[phone]


Cisco Systems
Village d'Entreprises Green Side bat. T3
400, Avenue Roumanille
06410 Biot - Sophia Antipolis
France
Cisco.com<http://www.cisco.com/global/FR/>

[Description: Description:                      http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg]

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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/roll