Agreed, and if something like Mark Handley's multipath transport is in use, several paths can be exploited in parallel without upper layer impact, and without even knowing whether they all work.
Dave is correct though that this assumes an engineering tradeoff; but surely we don't have to design for the worst case as if it was the typical case? Brian On 2008-12-23 12:25, Joel M. Halpern wrote: > Actually, there is at least one important additional factor. > It is not clear that it is necessary to find all working paths. > Given one working path, one might want to find a second early. > Given a suspicion that the two may have commonality, a background search > for more, while using the ones that work, is understandable. > > But communication does not need to wait on the O(n^2) search unless > finding pairs that work is rare. One does hope that normally most pairs > work. THis is actually a question about design targets. If we assume > that most paths are bad / non-working, then one needs lots of paths, and > some way to search among them very fast. > But I don't think that is our design center. > > Joel > > David Meyer wrote: >> Brian, >> >>>> Where I have N source addresses and M >>>> destination addresses, this is easily shown to be >>>> O(N*M). >>> Well, not quite, if you have an address selection algorithm >>> that excludes some combinations up front. >> >> With all due respect, what I said holds. I wasn't talking >> about optimizations, engineering considerations, or other >> constants (which I know you understand is what the notation I >> used is intended to convey). Its O(N^2), just >> like pairwise anything. >>> Also, do we expect >>> N or M to be >3 in many cases, or even >2 in most cases? >>> So I think the practical value will be less than you fear, >>> typically 4, and >9 would be very rare. Not that this is >>> negligible, but it's not unthinkable either. >> >> Ok, you say > 9 is rare, and maybe that's true, I have no >> clue. Sitting here today if each address represented an >> ISP, then it does seem like greater than some number >> would be rare (I would think 5 or so; who has 5 ISPs >> today?) >> BTW, can you support your assertion that > 9 is rare in >> any way?. >> So the problem is this: We say that > 9 is very >> rare. But suppose its not, and you and your correspondent >> both have 10 ISPs, or some combination of your ISPs gives >> you 10 addresses (10 makes for easy arithmetic, and is >> one more than your number [9]). In this case M=10 and >> N=10, and if you take the typical TCP timeout (3 sec in >> every *nix I have access to), then it takes (10*10*3)/60 = 5 >> minutes to determine that the host >> isn't reachable. Today a host can do the same thing in >> about 30 seconds. >> So yes, there are engineering assumptions that can be >> made, but the calculation still holds. That is the >> problem, not the list of all things that could go right. >> >> Dave >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rrg mailing list >> [email protected] >> https://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ > rrg mailing list > [email protected] > https://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
