Re: [RFC][PATCH 2/2] ip multipath, bk head (EXPERIMENTAL)

[jamal]

On Tue, 2004-09-14 at 01:42, David S. Miller wrote:
> On 13 Sep 2004 22:40:24 -0400
> jamal <hadi@xxxxxxxxxx> wrote:
> 
> > As long as whatever arrangement ensures that no packet reordering
> > happens, should be sane. Yes, current scheme is broken in some ways (but
> > guarantees packet ordering within a flow).
> 
> I think his changes ensure this as well, at least for local system
> sockets.  You'll only get a new hop each time a route lookup is
> performed, which is only done once per socket unless the path
> becomes "sick" and TCP decides to try and do a relookup of the
> destination.

I was worried more about forwarding path.

> I'm kind of ambivalent about these changes.  I definitely like the
> first patch which cleans up those huge functions in route.c :-)

Oh, yeah that looked good - thats why i didnt comment. Your call.

> But there are things I like about the current behavior, although I
> understand why people want things to work the way Einar is changing
> it to.

I think its a little broken but not unlike say CISCOs multipath when
they have caching. 
The general trend though is that now multipathing is getting more
interesting and the policy criteria is no longer loadbalancing alone.
An example interesting paper and newer devices showing up: 

"Experiences in Building A Multihoming Load Balancing System" by
Fanglu Guo, Jiawu Chen , Wei Li, Tzi-Cker Chiueh (State University of
New York at Stony Brook
url: http://www.ieee-infocom.org/2004/technicalprogram.htm

The idea proposed there is extensible to many other policy selections
(very easily implementable via tc actions).

cheers,
jamal


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/