Subject: [rbridge] PS issue #4

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 12 Dec 2005 14:40:10 -0500

Alia,

	I completely agree, now that I understand your earlier
comments a little better.  Suggesting use of a configurable
random "seed" value as an example of a mechanism to avoid
synchronization/correlation is okay.  Other approaches exist
as well - such as changing to use a different hash algorithm
(if that applies) or adding a shift or rotation operation to
the existing selection scheme.

	It is interesting to note that the effort to avoid the
synchronization problem must be stated as a _desirable_ goal
rather than a _requirement_ simply because - short of knowing
exactly what algorithms might be used and exactly what chain
of events can result in excessive correlation in arbitrarily 
many combinations of multipath selection schemes - it is hard 
to declare definitively that any specific avoidance approach 
will always work.

	I believe that - in other places - we have suggested
that whatever scheme might be used in any implementation, it
should include configurable parameters that may be used to
de-correlate the selection process from similar selection 
processes applied elsewhere in the network.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Alia Atlas
--> Sent: Saturday, December 10, 2005 3:04 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> Eric,
--> 
--> On 12/9/05, Gray, Eric <Eric.Gray at marconi.com> wrote:
--> >         Surely you don't really believe that a high level
--> > statement like "persistent re-ordering of flows MUST be
--> > avoided" is even close to the same as "and while you are
--> > doing that, make sure you twiddle this and tweak that."
--> 
--> Of course not - but we were talking in part about the 
--> tweaking of which
--> bits should be consulted, such as whether MAC addresses and VLANs
--> should be considered, or IP addresses, etc.  I agree that it's a bad
--> idea to include too much implementation detail, but I'm also not for
--> deliberate obfuscation.  I'm certainly not suggesting that 
--> one should
--> prescribe an algorithm; pointing out that randomness is needed to
--> ensure good multi-hop load-balancing doesn't strike me as being in
--> quite the same camp.  It's not like I'm saying how that 
--> randomness is
--> introduced, what that seed could be, etc.
--> 
--> Alia
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->