Subject: Re: Equal-cost path

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 13 Apr 2005 10:38:15 -0400

-> The correct answer would be "It's an implementation specific issue".
-> 
-> > On Sun, 10 Apr 2005, Ilan Bercovich wrote:
-> > 
-> > > When not using "equal-cost multipath",
-> > > Which equal-cost path should be selected?

 A good heuristic is - select a path where there are fewer
 number nodes along the path. Note that, IGPs don't include
 node weights in SPD (Shortest Path Dag) computation. But,
 nodes/routers are very crucial in forwarding traffic in the
 data path. 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.

Venkat.

---

From: Dave Katz <[email-masked]>
Date: Wed, 13 Apr 2005 11:47:50 -0700

On Apr 13, 2005, at 7:38 AM, Naidu, Venkata wrote:

>  If we assuming all nodes in an area have same

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

---

From: Erblichs <[email-masked]>
Date: Wed, 13 Apr 2005 15:31:50 -0700

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