Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Jun 2006 15:23:43 -0400
From:      David Gilbert <dgilbert@dclg.ca>
To:        =?ISO-8859-2?Q?=A3ukasz_Bromirski?= <lukasz@bromirski.net>
Cc:        'Baldur Gislason' <baldur@foo.is>, 'FreeBSD Net Mailing list' <freebsd-net@freebsd.org>, Christopher Martin <outsidefactor@iinet.net.au>, David Gilbert <dgilbert@dclg.ca>
Subject:   Re: Multiple routes to the same destination
Message-ID:  <17566.58047.18905.415605@canoe.dclg.ca>
In-Reply-To: <449ED6B8.9070009@bromirski.net>
References:  <20060623120208.GH36671@gremlin.foo.is> <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> <17565.30718.106118.318863@canoe.dclg.ca> <449ED6B8.9070009@bromirski.net>

next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "ISO" == ISO  <ISO-8859-2> writes:

ISO> David Gilbert wrote:
>> No.  round-robin will deliver packets out-of-order.  TCP will
>> behave very badly with this (at the very least, smart selective-ack
>> hosts will transmit a lot of selective-ack packets --- but dumb
>> non-selective-ack hosts will start asking for a lot of
>> retransmission).  Other protocols tolerance for OOO packets varies.

ISO> Yeah, but will give You flexibility in doing what You want to do
ISO> - for example, sharing two leased lines, 2Mbit/s each. There are
ISO> protocols that will behave oddly when they encounter OOB traffic
ISO> for TCP (like some BGP implementations for example), but FTP and
ISO> others tend generally to accept some low percent of such traffic.

Out-Of-Band, no.  You mistake what I said.  OOO refers to Out-Of-Order
above.  FTP will be no different than any other TCP based service.
The best behaviour will be extra traffic generated by the
selective-ack mechanisms (if they exist), the worst behaviour will be
retransmissions triggered for every out-of-order packet.

In the presence of multiple routes ... _even_ good similarly latent
routes, proper IP operation requires in-order-delivery for the vast
majority of protocols.  To do this, you must ensure that each stream
uses only one of the available routes.  The method by which you do
this is up to you.

>> Linux does all this with it's flow table --- that is each 5-tuple
>> of source ip,port dest ip,port (and protocol) is stored as a "flow"
>> in a big hash table.  The table stores things like the next-hop
>> interface and destination.

ISO> Yes, but having an option to do it per-packet or per-flow would
ISO> be wonderful. We don't have anything useable today (not counting
ISO> static policy-based routing done via ipfw, pf or netgraph). And
ISO> as we all know, implementation of flow-based routing can be
ISO> optimized to counter DDoS threats - Linux already did that in
ISO> 2.6.x, as there an option to compile kernel with either FIB_HASH
ISO> or FIB_TRIE.

Flow based routing in Linux is a travesty.  It falls down really
easily.  We tested linux and FreeBSD in routing environments and
hands-down, linux was a failure beyond trivial routing cases.  This
includes their latest incarnations.  I'm even fairly close to the
group that is trying to fix this.  Even in dedicated hardware, flow
based routing is a travesty (just look (and laugh) at any extreme
networks hardware running BGP).

Anyways... a "hashed" approach (that is where you take parts of the
address of the IP packet and use them to deterministically generate
the routing bits.

I would also like equal-cost-multipath, but I would like it done
correctly.  round-robbin is not correctly.

Dave.

-- 
============================================================================
|David Gilbert, Independent Contractor.       | Two things can be          |
|Mail:       dave@daveg.ca                    |  equal if and only if they |
|http://daveg.ca                              |   are precisely opposite.  |
=========================================================GLO================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17566.58047.18905.415605>