![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
| given TCP's inability to do congestion-sensitive backoff during | connection establishment, I'm not so sure that increasing the number | of concurrent connection attempts is a good idea. I am pretty sure it is NOT a good idea. | the selection of the server with the ... lowest [RTT] | was often ... good but rarely ... optimal. One of the things which is becoming apparent to a number of service providers is that that a low RTT is necessary but insufficient for "user happiness" - RTT _stability_ is often more important. Regrettably, there is little to no way for an end system to understand the short term stability of a path other than by trying to move traffic across it. | no, I can't see how a routing-system-based multihoming | will scale down to SOHO networks either. Why not? It should be an explicit goal of the next cut at an IPng, and shouldn't just stop at SOHO -- it should go right to individual homes, _at least_. I have multiple sets of wires coming into my flat, and live in a regulatory environment where each of those wires (and some new ones) is allowed to carry data/POTS/ISDN/cabletv/you-name-it. And then there's Sweden, which is several steps ahead. Check http://www.bredbandsbolaget.se/eng/node103.asp?ID=16 Yes, they really are serious about more than a quarter of a million homes which will have the moment-to-moment chance to use any or all of: FTTC/FTTB/FTTH from these folks, cable modems, or the various offerings from the various telcos (xDSL, dialup) for Internet connectivity. The days when only a handful of middle-aged Swedish women have broadband connections like this: http://www.stupi.se/Bilder/7296-3251-0759/g.html into their apartments are numbered. (BTW, if you look closely, you'll see her apartment's network was multihomed already.) The assumption that only larger organizations will want multihoming and at-will-provider-changing is a bad one. Sean.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.