On Mon, Nov 24, 2008 at 11:15 PM, Robin Whittle <[EMAIL PROTECTED]> 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 ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
