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>