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

Re: [RRG] Moving the problem to the global mapping system - fast-push

Robin Whittle wrote:

Short version:   There are many benefits to having fast-push of
                 mapping, so it is not just a simple trade-off.

                 For instance, with Ivip, there is no need to try
                 to anticipate all the ways end-users might need
                 to detect multihoming failure, or to make decisions
                 about how to change mapping, when to restore the
                 original mapping, how long a loss of connectivity
                 constitutes and "outage" etc.  The end-users do
                 all this themselves.
I looked up trade-off in the dictionary, and this is what I got: "a balance achieved between two desirable but incompatible features; a compromise".
So yes, of course you get unique, desirable features with your fast push system. I'm just trying to point out that you lose an incompatible, desirable feature: less control traffic and less processing of mapping updates. The rest of your e-mail makes a lot of arguments that Ivip's features are more desirable, and more than worth the cost. You may be able to convince people of this, but only if you can also convince people that it can actually work in practice, given the extra traffic generated. 


                 LISP, APT and TRRP developers need to try to make
                 their systems really complex and costly in order to
                 attempt to do as big a subset as possible of the
                 things end-users might want or need.
I can't speak about the other proposals, but the only thing APT intends to do for end-users is make sure the Internet keeps working as the expect, hopefully at the prices they expect. In fact, optimally, they wouldn't even know APT exists! APT is intended specifically to solve the routing scalability problem in transit networks. And this is my point about constraints -- primarily, we need to make sure we're solving the problem at hand! Extra features are a bonus, but should come second. 


With Ivip, the end-user has one multihoming monitoring system -
which won't overly burden the ETR, no matter how many ITRs are
sending data to it.  They set up their system (probably provided by
another company) to change the mapping according to whatever
criteria they like, including how long a loss of connectivity
constitutes an "outage".
It is going to take a VERY convincing argument, including real data analysis and/or simulations, to convince me that you can allow all end users to flood the whole network with mapping changes at the full capacity of their connection without causing a massive, network wide DDoS attack. Think about why we still need TCP congestion control on individual hosts on today's network. And that's just for point-to-point traffic! 


So fast-push makes Ivip modular and extensible to purposes end-users
really want, and which we cannot necessarily imagine at present.
Since there is a small fee per update, with Ivip we don't have to
fuss so much over "excessive" numbers of updates.
Assuming you are actually billing the person responsible. What if an unsuspecting user is generating a massive number of mapping updates because of a virus? 


I don't agree that by increasing the speed of mapping distribution
that Ivip necessarily increases the amount of mapping traffic.  If
you souped up APT's flooding technique (initially it was a BGP
flooding technique) to send the mapping data everywhere in 5
seconds, this wouldn't increase the amount of mapping data to send.
The issue is not how fast a given update can be propagated, but how many of these you allow. Ivip's desirable features do not just rely on getting a single update out in 5 seconds, but getting ANY update out in 5 seconds. This means having no rate limit on updates. This is the major problem, as I see it. 


At least Ivip has a birds-of-feather similarity to APT, in that both
involve hybrid push-pull systems, with local pull and robust notify
systems beyond wherever operators terminate the push system.


True. =)


However, moving mapping changes (for instance each one due to a
change in reachability, or a desire to do TE) to a much more
efficient system than BGP does lead to a much better situation.  If
the new system was as costly and difficult as BGP, then simply
moving the changes somewhere else wouldn't achieve much.
But what I'm trying to say is, if the new system is an order of magnitude more efficient, but has to handle an order of magnitude more control traffic, you're back where you started. 

-Michael


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg