The MPLS WG Archive
[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index]
Load balancing draft
-
From: "David Allan" <dallan@nortelnetworks.com>
-
Date: Thu, 21 Nov 2002 13:20:59 -0500
-
Cc: "'MPLS@UU.net'" <MPLS@UU.NET>
Title: RE: Load balancing draft
I don't follow why specific knowledge of boxes is required. The general effect is to englarge the scope of fate sharing between the probe stream and associated traffic. This would be independent of specific knowledge. If box 'A' randomizes stuff between B, C and D, and the probe pathologically follows B then C and D are not tested. If B randomizes stuff to boxes E F and G, and probes sticks with the associated traffic then E F and G are tested.
The only truly pathological case I can think of is when all load sharing points implement exactly the same algorithm and have exactly the same number of candidate NHLFEs and are only probed from a single point, otherwise incremental deployment of probe fate sharing pays dividends.
rgds
Dave
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Thursday, November 21, 2002 11:49 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'MPLS@UU.net'
> Subject: RE: Load balancing draft
>
>
>
> >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.
>
> In some cases it may help, but in others it does not which
> IMHO is the point. It is only useful if you know which
> boxes support which algorithms, which gets us back to
> where we are today.
>
> --tom
>
>
>
>
> >cheers
> >Dave
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau
> > [<mailto:tnadeau@cisco.com>mailto:tnadeau@cisco.com]
> > > 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; 'MPLS@UU.net'
> > > 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
> > >
> > >
> > >
>
> Success is relative; the more success, the more relatives. -Anonymous
>
>
>
| |
|