Subject: [rbridge] Summary 1 of load-balancing rbridges

From: Vishwas at sinett.com (Vishwas Manral)
Date: Sat, 13 Aug 2005 01:09:34 -0700

Joe,

One small thought.

> PS - one final thought. We don't really need to spec any of 
> this per se, IMO. We can mention that per-MAC or per-transportflow
> is fine, and that we leave it up to the rbridge implementation to 
> decide which to support. Again, so long as it's consistent within a 
> single rbridge device it need not be coordinated at all.
I agree we do not need to put the criteria for load balancing in the
spec. It would be ok to discuss it however. In my view it should be
configureable.

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Joe Touch
Sent: Saturday, August 13, 2005 3:29 AM
To: Joe Touch
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges

Joe Touch wrote:
> 
> 
> John Kristoff wrote:
> 
>>>On Thu, 11 Aug 2005 14:40:33 -0700
>>>Joe Touch <touch at ISI.EDU> wrote:
>>>
>>>
>>>
>>>>That's when it would be useful to peek into not only the IP, but
also
>>>>transport headers to mux across the pair of paths without reordering
>>>>within a transport connection.
>>>
>>>
>>>>From an operational perspective I'd prefer Alex's suggestion to use
>>>MAC addresses as the flow hash for load balancing.  It seems much
>>>simpler and seems to solve most of the problem.  Separate tools or
>>>other protocols can be used to achieve more perfect load balancing
>>>if it is needed.
> 
> 
> Load balancing by looking at IP and TCP headers is already common and
> solves the problem at hand (avoiding reordering within a transport
> protocol).
> 
> MAC-based load balancing, besides not helping with the case I cited,
> also fails for systems with multiple NICs that stripe a single
transport
> across multiple interfaces (e.g., channel bonding). Granted, they're
> sort of 'asking for it', but it seems OK to use a fairly common
> technique if it solves this problem too.
> 
> Joe

PS - one final thought. We don't really need to spec any of this per se,
IMO. We can mention that per-MAC or per-transportflow is fine, and that
we leave it up to the rbridge implementation to decide which to support.
Again, so long as it's consistent within a single rbridge device it need
not be coordinated at all.

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