Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

[Linda Dunbar <[e-mail]>]

Eric and Ken:

The current text explicitly says " sf1 would use local logic --  hash, state table, etc. -- to distribute the chained packets to sf2.".  To me this is not generic description. Why it has to be sf1 to choose which instance of sf2 for the chain? What if the decision is on SFF node?


If you want to make the text generic, I suggest removing the text on how SF1 having local logic to choose SF2, like:

"In the example shown in Figure 5, the load distribution decision for SF2 can be localized at nodes to which SF2 is connected
(though the decision may be affected by a macro policy provided in some  form by the control entity)."


"The load distribution decision will be localized (in general, although there might
   be macro policy controlling that"

Linda

-----Original Message-----
From: Ken Gray (kegray) [mailto:[e-mail]]
Sent: Thursday, May 29, 2014 9:41 AM
To: Eric Gray; Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
Cc: [e-mail]
Subject: Re: [sfc] questions of "load balancing considerations" in the draft-quinn-sfc-arch-05

Yep, can see how it is a bit too "thick".  I'm okay with your suggested simplification.

On 5/29/14 10:25 AM, "Eric Gray" <[e-mail]<mailto:[e-mail]>> wrote:

>Linda,
>
>       A few points:
>1) probably better not to use MS Word (assuming that is what you used)
>to add comments to your mail (not sure many people will be able to read
>them); best to simply include your comment(s) directly.
>2) being careful about providing text to ensure that the right context
>is included can help to understand your point.
>3) your comments appear (as Ken pointed out in a separate response) not
>to be
>     based on what any of us said; in fact, it looks like what you
>really mean is "based
>     on my understanding of what you have said" as a way to make a
>separate (but
>     related) point.
>
>In your first point, a more complete context would be included if you
>quoted this:
>
>"The load distribution decision will be localized (in general, although
>there might
>   be macro policy controlling that - which is out of scope for the
>sake of a simple
>   example).  In this case, the control entity will push to the sf1
>nodes, a table of
>   sorts: sf2 with a series of next hops, and if needed some weighted
>or other
>   metrics (these could also be decided locally by some policy, but sf1
>would need
>   to be aware of expand/contract triggers and actions).  sf1 would use
>local logic --
>   hash, state table, etc. -- to distribute the chained packets to sf2."
>
>This is the entire paragraph, after the first two sentences.
>
>I believe the issue with this text is that the authors have improperly
>parenthesized text, making the meaning of this paragraph
>self-contradictory and rather opaque on first reading it.
>
>In fact, grammatically speaking the entire paragraph is a mess - and
>that does not help in understanding it.
>
>The way I have puzzled it out, the text "[in] this case, the control
>entity will push to the sf1 nodes, a table of [some sort: e.g.  - ] sf2
>with a series of next hops, and [(if needed)] some weighted or other
>metrics" applies to the text in parentheses in the preceding sentence
>(i.e. - "in general, although there might be [a] macro policy
>controlling that - ...").  In other words, "this case" refers to the
>case where a macro policy is used to control the "local decision"
>process.
>
>As you can see from the way I have hacked up the sentences in my effort
>to make sense of them, and the amount of restructuring I think the text
>requires, it is my opinion that the text needs a major rework.
>
>For one thing, the complex example given actually doesn't help and
>should not be included.
>
>Assuming I have the meaning correct, I would replace the quoted text
>above with:
>
>"In the example shown in Figure 5, the load distribution decision for
>SF2 is localized
>  at SF1 (though the decision may be affected by a macro policy
>provided in some  form by the control entity)."
>
>The rest of the previous text only adds confusion as a result of
>over-stating the example.
>
>As a matter of personal preference, I would also use the word "embedded"
>as
>the better-known spelling of the word "imbedded" used in the first
>sentence (and possibly elsewhere in the draft).
>
>I agree with Ken that your second suggested change is incorrect.
>
>--
>Eric
>
>
>
>From: sfc [mailto:[e-mail]] On Behalf Of Linda Dunbar
>Sent: Wednesday, May 28, 2014 5:50 PM
>To: Ken Gray (kegray); Paul Quinn (paulq); Joel M. Halpern
>Cc: [e-mail]<mailto:[e-mail]>
>Subject: Re: [sfc] questions of "load balancing considerations" in the
>draft-quinn-sfc-arch-05
>
>Joel, Eric, and Ken,
>
>Thank you very much for the explanation.
>
>Based on what you said, the description on how "control entity  push to
>the sf1 nodes ." should be removed from the text, specifically:
>
>"In this
>   case, the control entity will push to the sf1 nodes, a table of
>   sorts:  sf2 with a series of next hops, and if needed some weighted or
>   other metrics (these could also be decided locally by some policy,
>   but sf1 would need to be aware of expand/contract triggers and
>   actions)."
>
>
>Should also change the sentence after the Figure 5 to
>
>"Either through an imbedded action in sf1 and sf3, the SFF nodes to
>which the multiple instances of SF2 or SF4 are attached, or through external
>   control, the service functions sf2 and sf4 are elastically expanded
>   and contracted dynamically."
>
>
>Linda
>From: Ken Gray (kegray) [mailto:[e-mail]]
>Sent: Wednesday, May 28, 2014 4:24 PM
>To: Linda Dunbar; Paul Quinn (paulq); Joel M. Halpern
>Cc: [e-mail]<mailto:[e-mail]>
>Subject: Re: [sfc] questions of "load balancing considerations" in the
>draft-quinn-sfc-arch-05
>
>+1 to Joel . the picture would be ugly at best.  We attempted a generic
>HA/LB slide to make a point and even it was ugly .such are the
>limitations of ASCII art.
>
>In line .
>
>From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
>Date: Wednesday, May 28, 2014 3:34 PM
>To: "Paul Quinn (paulq)" <[e-mail]<mailto:[e-mail]>>, "Joel M. Halpern"
><[e-mail]<mailto:[e-mail]>>
>Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
>Subject: [sfc] questions of "load balancing considerations" in the
>draft-quinn-sfc-arch-05
>
>Paul and Joel,
>
>Does the Load Balancing Figure 5 (of draft-quinn-sfc-arch-05) assume
>that
>SF1 is responsible for balancing traffic among the 3 instances of SF2,
>and SF3 is responsible for balancing traffic among the 3 instances of SF4?
>
><keg> Document text below the picture says "Either through an imbedded
>action in sf1 and sf3, or through external control, the service
>functions sf2 and sf4 are elastically expanded and contracted
>dynamically."
>
>Isn't it a single point of failure?
>
><keg> Document text immediately subsequent to that picture and
>paragraph illustrates HA scenarios.
>
>Some service functions are Stateful, i.e. they may require packets from
>same flows to traverse the same service function instance. For the Load
>Balancing scheme described by Figure 5, do you assume that SF1 and SF3
>will be responsible for making sure that same flows go through the same
>service function instance?
>
><keg> Again, the aforementioned text deliberately allows this
>responsibility to be either imbedded in the elasticity-causing function
>or to be controlled externally or centrally.  We don't get into the
>mechanics as these can vary.  While stateful/bidirectional does add an
>additional burden, it can be accommodated without an explosion of
>discrete chains.  For example, it could be handled "at allocation time"
>if elasticity is managed via a separate entity and the individual
>allocations reflected through service chain control in the initial
>metadata bound to at the classification point in either direction.  OR,
>if the devices are working as a paired system (single vendor or
>ecosystem) with integrated elasticity, they could pass metadata between
>them when sf1 or sf3 does the initial dynamic allocation (affecting
>local forwarding on it's partner).  That's probably not an exhaustive
>list of ways to solve the problem.  8^)
>
><keg> The point of this section was that elasticity and HA should not
>cause an inordinate explosion of discrete chains without recommending a
>particular solution.  That is,  you shouldn't create unnecessary
>complexity where it doesn't need to exist.
>
>For the stateful service functions, if a flow is switched from
>SF-Instance-X to SF-Instance-Y, the SF-Instance-Y needs to synchronize
>the states from SF-Instance-X. Who is responsible for those states
>maintenance for the Load Balancing described in Figure 5?
>
><keg> None of those entities exist in Figure 5.  Can you re-phrase your
>question from the figure?
>
>Linda
>