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

[Brian E Carpenter <[e-mail]>]

On 24/10/2012 15:40, Ralph Droms wrote:
> Seems to me this conversation ought to include 6man fairly soon.

If ROLL wants to go this way, I agree. I *think* the proposal does
no violence to the 6man RFCs, but that's only my opinion.

    Brian

> 
> - Ralph
> 
> On Oct 24, 2012, at 4:14 PM 10/24/12, Pascal Thubert (pthubert) wrote:
> 
>> Hi Brian,
>>
>>> The worst case I can see from this approach is that all packets with the same source/dest address pair would get the same flow label and hence be treated the same for ECMP, LAG or any other kind of load balancing
>> This is actually not the case. 
>>
>> A same node may participate to multiple instances, each instance designed to serve a certain class of traffic with a certain optimization. 
>> With the proposal, the instance-ID is stamped in the flow label.
>> The root will probably use the instance-ID for the computation of the final flow label, so that packets received over a same instance are treated the same over the core. 
>>
>> This is true whether the packets are from a same or from multiple sources. So the root may or may not aggregate multiple sensors (field devices) in a same flow - or not.
>>
>> For some applications such as industrial control flows, jitter and latency are critical, and it is good that different sources are treated the same, thus considered a same flow.
>> This would be difficult to coordinate ifs the sensors themselves were in charge of computing the label but is an obvious thing to do for the root.
>>
>> Cheers,
>>
>> Pascal
>>
>>
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]] 
>> Sent: mercredi 24 octobre 2012 16:00
>> To: Pascal Thubert (pthubert)
>> Cc: Owen Kirby; [e-mail]
>> Subject: Re: [Roll] using the flow label instead of hop by hop
>>
>> The worst case I can see from this approach is that all packets with the same source/dest address pair would get the same flow label and hence be treated the same for ECMP, LAG or any other kind of load balancing. That will arise if the flow label has to be calculated based only on the address 2-tuple due to fragmentation. I don't see that as a disaster - a lot of load balancing is already based on the 2-tuple anyway.
>>
>> The revised flow label spec explicitly allows the case where it's a router (often but not necessarily the first hop router) that sets the flow label, iff the source doesn't do so. As far as I understand the proposal, it's compatible with that.
>>
>> Regards
>>   Brian Carpenter
>>
>> On 20/10/2012 09:09, Pascal Thubert (pthubert) wrote:
>>> 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
>>>
>>>
>>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
> 
>