Subject: RE: Load balancing draft

From: "David Allan" <[email-masked]>
Date: Thu, 21 Nov 2002 11:11:35 -0500

Tom:

Not entirely true, any point where there is useful predictability reduces
the number of possible faults that may only be caught by random process.
IMHO that is useful.

cheers
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 10:59 AM
> To: Fedyk, Don [BL60:1A00:EXCH]
> Cc: George Swallow; Fedyk, Don [BL60:1A00:EXCH]; Allan, David
> [CAR:NS00:EXCH]; Alia Atlas; Shahram Davari; [email-masked]'
> Subject: Re: Load balancing draft
> 
> 
> 
> >George
> >
> >Let me restate. You Said "All load balancing done in 
> prescribed manner." 
> >Which is certainly restrictive. The Draft for load balancing 
> says  not to 
> >use certain fields. That is not the same. So I added different 
> >implementations for load balancing following the draft still 
> have freedoms 
> >and different vendors can choose different algorithms.
> 
>          Not really. If you want things to work the way the 
> draft aspires
> them to, then everyone in the MPLS domain must use the same,
> predictable load balancing algorithm.  Going halfway doesn't work,
> and is arguably no better than what we have today.
> 
>          --Tom
> 
> 
> >Hope that makes it clear,
> >Don .
> >George Swallow wrote:
> >
> >>Don -
> >>
> >>This seems to a non-sequitor.  I don't see how this comment 
> relates to
> >>what I wrote below.  Were you trying to answer some other message?
> >>
> >>...George
> >>
> >>
> >>
> >>>George to be fair I heard Dave say  that the load 
> balancing should not 
> >>>use certain fields which are part of the label stack. This 
> does not 
> >>>require that balancing be done in a prescribed manner, 
> freedom is still 
> >>>there. Instead load balancing should be correct with 
> respect to all of 
> >>>MPLS formats  including reserved labels.
> >>>
> >>>Don
> >>>
> >>>George Swallow wrote:
> >>>
> >>>
> >>>
> >>>>>If you look at my post from rather late last night, I'd 
> question the 
> >>>>>lighter
> >>>>>overhead assertion. This discussion is really orthogonal 
> to the probe
> >>>>>frequency and is more concerned with the probe 
> quantity/quality to 
> >>>>>determine
> >>>>>there is a problem. Goodness and scalability (and again 
> my favorite 
> >>>>>"bounded
> >>>>>detection time") can be expressed as how authoritative a 
> test result is in
> >>>>>proportion to the messages expended. Also the fewer 
> heuristics required to
> >>>>>interpret the test results, the more reliable the 
> overall system is....
> >>>>>
> >>>>>
> >>>>My only point is that if your measurement is based on the 
> assumption
> >>>>that all load-balancing is being done in a prescribed 
> manner, then the
> >>>>quality of that measurement is very much dependent on the 
> certainty
> >>>>that all of the nodes in the path are actually behaving 
> according to
> >>>>that assumption.  On node behaving differently could 
> reroute a large
> >>>>portion (or all) of the probes.  Thus the measurement could be far
> >>>>
> >>>>
> >>>>from the actual behavior.
> >>>
> >>
> >>==================================================================
> >>George Swallow       Cisco Systems                  (978) 497-8143
> >>                     250 Apollo Drive
> >>                     Chelmsford, Ma 01824
> >>
> >>
> >
> 
> Success is relative; the more success, the more relatives. -Anonymous
> 
> 
>

---

From: Don Fedyk <[email-masked]>
Date: Thu, 21 Nov 2002 14:59:24 -0500

Tom

You can have MPLS Load balancing that :
1) Follows a predictable algorithm (for a reasonable duration) on each 
box based on some header fields.
2) Does not use fields that overlap with prescribed fields in the draft 
(Reserved label, Stack bit etc.).
3) Follows an identical, globally the same, (and hence predictable and 
repeatable)  algorithm on each box.

(1) is what we have today.
(1) plus (2) are what we would recommend. (and even might be on some 
boxes today).
(2) plus (3) is overkill (and impractical to deploy and is restrictive). 
I think we agree nobody is saying this one.

Don

Allan, David [CAR:NS00:EXCH] wrote:

> Tom:
>
> Not entirely true, any point where there is useful predictability 
> reduces the number of possible faults that may only be caught by 
> random process. IMHO that is useful.
>
> cheers
> Dave
>
<snip>