> But seriously, it shouldn't be necessary to have two connections at
> work, two connections at home, two connections for each mobile device,
> just to ensure that when large providers stop working together you can
> still reach what you need to reach.
I think you're misinterpreting what I'm trying to say.
The consumers/end-users don't necessarily have to multihome. The problem is
the content providers/web hosters sitting single-homed on either networks,
when most of them are physically sitting in better environment to multihome
(i.e. a datacenter) than consumers.
A consumer can be single homed to Sprint or Cogent, but when the other side
(the content) is multihomed, you'll simply take new route to get to that
content. My point is, any business providing services over internet (this
excludes mobile devices, end-user/consumers) should be multihoming
themselves if they are serious about uptime.
So my Sprint EVDO (hypothetical, not real) can't get to the DSL line I've
got through $cheap-Cogent-bandwidth-DSL-provider (also hypothetical, not
something I have, but I know of such a provider. Given they're not at
fault in this dispute, I will not name them.) So what you're saying is
that I'm expected ... to go get myself some space in a data center so that
I can buy some more Internet connectivity in the data center so that I can
bounce my VPN connection from my laptop to my home office via the data
Let's try to remember that the Internet isn't the sort of "content provider"
and "end-user" thing you're pretending it is. This model is loosely true
for some large percentage of traffic, but it is by no means the only usage
Further, why should content networks be taxed extra in the manner you
Are you willing to mandate that customers in Sprint and Cogent colocation
centers must be offered reasonable pricing on connections to alternate
You really don't want all your content providers multihoming in any case,
there are far too many of them, and encouraging each one to solve its own
connectivity problem will result in an explosion of the routing table.