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

["Ken Gray (kegray)" <[e-mail]>]

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]> 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]
>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]
>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]>
>Date: Wednesday, May 28, 2014 3:34 PM
>To: "Paul Quinn (paulq)" <[e-mail]>, "Joel M. Halpern"
><[e-mail]>
>Cc: "[e-mail]" <[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
>