Re: Equal-cost path

[Erblichs <[e-mail]>]

Group, et al,

	I would like to agree with Dave Katz.

	However, I would like to expound on just a
	couple of items.

	First, at the hardware layer, in my experience
	with Ethernet, you want to bunch packets together
	so as to be able to process a group of packets
	with a single interrupt.

	Secondly, if we assume OSPF control Updates with
	new link information, I would hope that these
	would be processed together and generate only
	1 later computation.

	Thirdly, if we are looking at a single data
	stream that in theory has a set of packets being
	handled on both ends by TCP, if only a singe
	TCP packet is delayed or expedited and arrives
	out of order, we can easily generate a false
	fast retransmit.

	Fourth, most TCP paths need a baicly constant flow of
	packets in-flight to determine congestion and be
	able to run network limited flows vs application
	limited flows. With the later, and any changes, the
	end-points are unable to determine whethe the
	those paths have changed wrt congestion behaviour.

	So in theory spreading the load over multiple paths
	is not a panacea, but is a sensible thing to determine
	congestion over the different paths, and to be able
	to generate predictable time measurements.

	Mitchell Erblich
	------------------------

Dave Katz wrote:
> 
> On Apr 13, 2005, at 7:38 AM, Naidu, Venkata wrote:
> 
> >  If we assuming all nodes in an area have same
> >  capabilities (like, line rate forwarding etc), fewer number
> >  node path performs better in the average case.
> >
> 
> I do not believe that you can make this claim, except in a simulation,
> which has little to do with reality.
> 
> In real networks, with reasonably fast routers and links, the
> performance of the routers and per-link serialization are greatly
> overwhelmed by other issues (such as the speed of light and queue
> lengths.)
> 
> One could just as plausibly posit that, on average, a random assignment
> in the case of equal path costs could improve performance by spreading
> the load more effectively across the infrastructure, but it totally
> depends on the particulars of equipment, topology, and traffic.
> 
> A case could also be made that well-engineered networks ought not to
> have equal cost paths by accident;  most of the time they should only
> appear if the network engineers wanted to take advantage of path
> splitting.
> 
> In any case, a router that did not support equal cost multipath would
> be so broken that nobody would buy it, making the whole question
> academic.
> 
> --Dave