[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Equal-cost path
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