[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is multihoming hard? [was: DNS amplification]

On Mar 22, 2013, at 15:44 , <Valdis.Kletnieks at vt.edu> wrote:

> On Wed, 20 Mar 2013 15:16:57 -0500, Owen DeLong said:
>> On Mar 20, 2013, at 9:55 AM, Seth Mattinen <sethm at rollernet.us> wrote:
>>> Based on the average clue of your average residential subscriber (anyone
>>> here need not apply) I'd say that's a good thing.
>> If BGP were plug-and-play automated with settings specified by the provider,
>> what would the user's clue level have to do with it?
> The hypothetical existence of such a box doesn't change the fact that
> providers have to make business decisions based on actual boxes and users.
> Yes, if a plug-n-play idiot-proof BGP box existed, then the profit calculus
> would be different.  On the other hand, if there existed a reliable
> cost-effective means for faster-than-light signaling, if would drastically
> change intercontinental peering patterns. All the same, anybody who's planning
> their interconnects in 2013 reality and not looking at who has 40K km of
> underwater cable and who doesn't is in for a surprise....

There is a difference and you know it.

A reliable cost-effective means for FTL signaling is a hard problem without
a known solution.

An idiot-proof simple BGP configuration is a well known solution. Automating
it would be relatively simple if there were the will to do so.

However, the reality is that ISPs don't want the solution for a number of reasons:

1.	ISPs are actually motivated to prevent customer mobility, not enable it.
2.	ISPs are motivated to reduce, not increase the number of multi-homed
	sites occupying slots in routing tables.

In addition, most of the consumers that could benefit from such a solution
do not have enough knowledge to know what they should be demanding
from their vendors, so they don't demand it.

This is a classic case of the "invisible hand" only works when all participants
have equal access to information and relatively equal knowledge. The problem
with technical products and especially with technical based services products
is that the vendor consistently has much greater knowledge than the
subscriber and is therefore in a position to optimize for the vendors best
interests even when they are counter to the best interests of their customers.