Subject: [rbridge] PS issue #4

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 9 Dec 2005 09:49:30 -0500

Alia,

	Actually, this is getting more into implementation 
than I believe we should.  It may be sufficient for us to
recommend injection of some random factor into <whatever>
path selection algorithm - obviously during initialization
- in order to avoid synchronization problems during path
selections.  

	Conversely, we could view this as telling people not 
to build bad implementations - which is not what we should 
be doing.

	After all, our employers are not generally motivated
to tell other companies how to build a better mouse trap.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Alia Atlas
--> Sent: Friday, December 09, 2005 2:24 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] PS issue #4
--> 
--> On 12/8/05, Gray, Eric <Eric.Gray at marconi.com> wrote:
--> >         Any specific path selection algorithm affects only the
--> > device making the path selection.  That means it comes under
--> > the heading of "what I do in my box is my own business."
--> >
--> >         What really needs to be said - particularly at a level
--> > of "architecture" is that devices using multiple paths to
--> > forward frames MUST use some path selection algorithm that
--> > will prevent persistent re-ordering of frames within flows.
--> 
--> It may also be worthwhile to point out that a different 
--> seed into the
--> hash function at each
--> point is important to improve load-balancing at different rbridges
--> along a path.  Otherwise, there is the risk that, in the 
--> trivial case,
--> only traffic with hash x will reach an rbridge from a particular
--> interface so that when that rbridge tries to load-balance by using
--> hash x and y, it only has hash x traffic and no 
--> load-balancing occurs.
--> 
--> I think this is important at the "architecture' because, without it,
--> load-balancing is at risk of working very poorly for sequential
--> rbridges that have ecmp.
--> 
--> Alia
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: akatlas at gmail.com (Alia Atlas)
Date: Fri, 9 Dec 2005 10:40:17 -0800

Eric,
> - in order to avoid synchronization problems during path

If we feel the need to discuss that there is a hashing algorithm
to avoid frequent per-flow re-ordering, then I'd have just have
that recommendation.

> to build bad implementations - which is not what we should

One could view telling people not to reorder flows as the same thing.

Alia

> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
>