Subject: RE: [Int-area] Last Call: <draft-ietf-intarea-flow-label-balancing-01.txt> (Using the IPv6 Flow Label for Server Load Balancing) to Informational RFC

From: "George, Wes" <[email-masked]>
Date: Mon, 16 Sep 2013 11:49:26 -0400

I've reviewed this draft, and have one substantive comment:

I think within the operational considerations (and possibly the info model), you need some discussion of diagnostics and troubleshooting, both for on-box and off-box implementations. How do I see that it's working properly, and how do I diagnose problems when it's not?
One of the problems with the existing hashing algorithms is that they are often opaque, such that it's not clear what the device is doing, whether the hashing is working properly and the flows are of the sort that create imbalanced distribution, or whether hashing has broken somehow -- occasionally you can get info, but it's usually hidden commands, with difficult-to-interpret responses, and it's not like most vendors publish their "secret sauce" optimizations of hashing so that it's easy to predict what will happen given a certain set of flows.
In order for this to be operationally manageable, especially in the case of on-router processing of this rebalancing, there has to be an easy way for the operator to access the information about what's happening - what the result would be if the flows were balanced according to the hash vs what is happening as a result of rebalancing, so that they can chase down things like rebalancing misses or situations where this local optimization is creating a problem elsewhere in the path because that device did something different in its attempts to balance better, etc. It may also be that this info is necessary to properly tune the frequency of sampling, the thresholds for things like long-lived vs short-lived flows, etc. to the specific network where it is being used.
I realize that in the model you've proposed, we're somewhat limited because this is using sampled flow data instead of the realtime packet hash. It may be that this drives a requirement for the granularity of data being brought into the system in the external mode, and some requirements about the level of information available via the UI (or SNMP or XML or whatever) in the automatic hardware-based mode.

Thanks
Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of The IESG
> Sent: Monday, September 16, 2013 9:43 AM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [Int-area] Last Call: <draft-ietf-intarea-flow-label-balancing-
> 01.txt> (Using the IPv6 Flow Label for Server Load Balancing) to
> Informational RFC
>
>
> The IESG has received a request from the Internet Area Working Group WG
> (intarea) to consider the following document:
> - 'Using the IPv6 Flow Label for Server Load Balancing'
>   <draft-ietf-intarea-flow-label-balancing-01.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-09-30. Exceptionally, comments may
> be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document describes how the IPv6 flow label as currently
>    specified can be used to enhance layer 3/4 load distribution and
>    balancing for large server farms.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-
> balancing/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.

Anything below this line has been added by my company's mail server, I have no control over it.
-----------------

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.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 16 Sep 2013 16:54:14 -0400

Please disregard, these comments are intended for draft-ietf-opsawg-large-flow-load-balancing-05. I replied to the wrong thread. Sorry for the spam.

Thanks,

Wes

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> George, Wes
> Sent: Monday, September 16, 2013 11:49 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Int-area] Last Call: <draft-ietf-intarea-flow-label-
> balancing-01.txt> (Using the IPv6 Flow Label for Server Load Balancing)
> to Informational RFC
>
> I think within the operational considerations (and possibly the info
> model), you need some discussion of diagnostics and troubleshooting,
> both for on-box and off-box implementations. How do I see that it's
> working properly, and how do I diagnose problems when it's not?
> One of the problems with the existing hashing algorithms is that they
> are often opaque, such that it's not clear what the device is doing,
> whether the hashing is working properly and the flows are of the sort
> that create imbalanced distribution, or whether hashing has broken
> somehow -- occasionally you can get info, but it's usually hidden
> commands, with difficult-to-interpret responses, and it's not like most
> vendors publish their "secret sauce" optimizations of hashing so that
> it's easy to predict what will happen given a certain set of flows.
> In order for this to be operationally manageable, especially in the case
> of on-router processing of this rebalancing, there has to be an easy way
> for the operator to access the information about what's happening - what
> the result would be if the flows were balanced according to the hash vs
> what is happening as a result of rebalancing, so that they can chase
> down things like rebalancing misses or situations where this local
> optimization is creating a problem elsewhere in the path because that
> device did something different in its attempts to balance better, etc.
> It may also be that this info is necessary to properly tune the
> frequency of sampling, the thresholds for things like long-lived vs
> short-lived flows, etc. to the specific network where it is being used.
> I realize that in the model you've proposed, we're somewhat limited
> because this is using sampled flow data instead of the realtime packet
> hash. It may be that this drives a requirement for the granularity of
> data being brought into the system in the external mode, and some
> requirements about the level of information available via the UI (or
> SNMP or XML or whatever) in the automatic hardware-based mode.
>
> Thanks
> Wes George
>
> balancing/
> 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.