[rrg] Fundamental objections to a host-based scalable routing solution

[William Herrin]

On Mon, Nov 24, 2008 at 11:15 PM, Robin Whittle <rw at firstpr.com.au> wrote:
>> By contrast, a multiple-LOC multihomed host could detect the failure
>> of one of its LOCs (the one associated with the failed link) within a
>> few hundred milliseconds and switch to using just the LOCs which still
>> work. Detection is straightforward: if you're round-robining through
>> the available LOCs as you send packets, the failed LOC sets are the
>> ones that stop reliably returning responses.
>
> I can't see how every multihomed host could be required to
> continually test reachability with extra packets, or that it would be
> good to have each host sending out packets through multiple ISP links
> as a means of detecting an outage.

Who said anything about sending extra packets? The payload packets are
the test. The acks (or their absence) are the response to the test.

>  I think that the technique you
> describe relies on the the application getting ACKs, and recognising
> when they don't arrive - and then telling the stack about it.  This
> doesn't sound robust to me.

Seems to work OK for TCP.

> Also, any one host doesn't necessarily
> have multiple sessions going on to be spread round-robin style over
> multiple ISP links, each involving a different IP address for this host.

Unless the app has requested a consistent locator pair (a phone app
might do so to get consistent round trip times), you use all available
locators in a single session. Packet 1 from locator A. Packet to from
locator B. Packet 3 from locator A again. Actually, you'll probably
want to switch off sets. Source A Dest X, Source B Dest Y, Source A
Dest Y, Source B Dest X. Then you measure characteristics of the
various choices like time-to-ack and percentage loss in order to
weight packets towards the best set.

That sort of path optimization is something a network-level device
really can't do. You have to keep session state to attempt it and
session state is too heavy weight for a network device.


Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004