[rbridge] PS issue #4

[Alia Atlas]

Eric,
On 12/9/05, Gray, Eric <Eric.Gray at marconi.com> wrote:
>         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.

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.

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

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

Alia

>         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
> -->
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
>