[rbridge] PS issue #4

[Gray, Eric]

Alia,

	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."

	This discussion, high level and detail, has come
up numerous times in the past few years.  While I have
seen people add a high-level comment similar to the one
above to documents that eventually became RFCs, I have
not seen people successfully detail how to do it.  I
believe that most people believe it is just a bad idea
to include too much detail in normative text.  I'd be 
happy to hear of counter-examples, however.

	There is a certain amount of "mom and apple-pie" 
that makes sense to add to a standard protocol spec. 
Beyond that is simply filler...

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