Re: [v6ops] Server load balancing using the flow label

Thanks, Wes, good comments that I pretty much agree with.

As for reflecting the same flow label back, it isn't immediately
obvious why this would help, but (skipping a longish argument about
uniform statistical distribution of flow labels) I don't think it
can possibly be harmful. You could do it quite cheaply by saving the
inbound label in the TCB at syn/ack time.

Regards
   Brian

On 2011-11-01 03:56, George, Wes wrote:
> I've read and support this being discussed/adopted
> 
> Some specific comments:
> 
> DNS-based loadbalancing is a good bit more complicated in a lot of cases, and as you note, may be used in combination with other methods. While it may still fall out of scope for this document, you may want to consider the case where a DNS server is involved in some manner of coarse geographical distribution of requests, either to a formalized CDN or simply to a more regionally-appropriate data center. I don't think that it materially changes the way that FL would be handled, but might be worth mentioning for the sake of completeness.
> 
> To the meat of the document:
> I think you're missing an opportunity for some clearer and stronger language regarding implementation of the flow label as described in 3697bis given your audience on this draft. A lot of the traffic in the case you're discussing is asymmetric, with the far larger flow occurring in the opposite (outbound) direction. While it is interesting to use this in the inbound direction as a means to manage server load, a couple of things to consider:
> 1) draft should strongly recommend that the source servers implement 3697bis on *outbound* traffic so that the networks in the path may use that to enhance load-balancing (via 6man-flow-ecmp) - if they're going to the trouble of using flow label as another input to improve inbound LB, it follows that they'd want to be able to take advantage of it in the opposite direction, and there may be some considerations involved in doing this at scale in a scenario with hundreds of servers behind a single set of uplinks, especially involving FL collisions and how they are handled.
> 2) When both ends have implemented 3697bis, I'm wondering if there are any considerations/benefits to using the same flow label value in each direction? That is, both the HTTP GETS and the responses use the same FL? While typically these are considered different flows, I'm thinking that perhaps there is value in being able to see the traffic as a consolidated flow. It would require some state or an algorithm to drive this behavior, and that is not currently covered in the FL drafts. I haven't given that a huge amount of thought yet, so I submit it for the WG's review...
> 
> Wes George
> 
> 
>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
>> Of Brian E Carpenter
>> Sent: Wednesday, October 26, 2011 5:07 PM
>> To: IPv6 Operations
>> Subject: [v6ops] Server load balancing using the flow label
>>
>> Hi,
>>
>> If you haven't done so, please have a look at
>> https://datatracker.ietf.org/doc/draft-carpenter-v6ops-label-balance/
>>
>> We'd like to briefly introduce this in Taipei, but some feedback before
>> then would be very helpful. It's a fairly simple draft relying on the
>> updated flow label standard that is in the RFC Editor queue. We can
>> discuss whether it belongs in v6ops, but it doesn't define any new
>> protocol.
>>
>> --
>> Regards
>>    Brian Carpenter + Sheng Jiang
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> 