On Sat, Jan 23, 2010 at 7:06 AM, Robin Whittle <r...@firstpr.com.au> wrote:
> > From a routing scaling point of view (ignoring my concerns about > burdening all hosts with extra responsibilities) I think the trouble > with CEE approaches is that they only provide scaling benefits when > an adopting network can either: > > 1 - Give up its current PI space and work from the PA space from > its one, two or more ISPs. > > or > > 2 - Migrate from reliance on its current (non-portable, no > multi-homing) PI space to the new system of identity (AKA edge) > addresses in a way which provides portability, multihoming and > TE. I prefer approach 2, think this is the best way to go since that what has been done in the cell-phone network - the subscriber owns the number and can choose which ever service provider he/she prefers. So we should keep this model in the Internet as well. >> >> Totally new host protocols might not be needed, you could get around >> most of the challenges by adding extensions to existing protocols. > > OK - I agree, but even altering applications is very difficult. > Also, I think it would be a nightmare to have an application with two > different ways of communicating with other hosts - the conventional > approach and some CEE approach. > You might be able to design the CEE architecture in such a way that most applications do not see the difference, if the approach is enough backwards compatible. Of course you get into trouble with applications that uses IP-addresses in their payload - but these applications are already having troubles with NAT traversal > > For a host to use the new CEE system, as far as I know, its > applications all need to be rewritten to use it as well, and the > stack and its API needs to be changed as well. > Nope, not all CEE approaches > There may be CEE architectures which work entirely with existing API > and applications, but I can't think of one now that would work. > Well, there is one that might work around the problem > So its not just a network deciding to adopt a new system, upgrading > their operating systems etc. It also requires that all their > applications be rewritten. I can't imagine how this would ever > happen - especially since I can see how mobility, scalable > portability, multihoming etc. can be done with a CES system and no > host changes at all. > Agree, if every application needs to be rewritten we are in serious trouble > > I think the CEE proposals differ enormously from CES proposals in > their ability to meet the constraints which arise from the need for > voluntary adoption. The only attempt I know of to state these > constraints is my page: > > http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ > > This is my text, refined after some RRG discussions. I don't know of > anyone who thinks these constraints are invalid, though 8, 9 and 10 > are sliding scale constraints and the rest are absolute, so there is > debate about how much 8, 9 and 10 matter on a case-by-case basis. > > A CES architecture which does not significantly affect performance, > security etc. could satisfy all 10 constraints. I think Ivip would > satisfy them all. I think LISP-ALT or any system which relies on a > global query server system for mapping should be able to satisfy all > but point 9 (performance) - due to the "initial packet delay" > problem. With ALT, this is actually a problem of "initial packets > get dropped until the one is sent after the ITR gets the mapping". > > No CEE architecture can meet any of the constraints 1 to 5. > Had a look on those and some comments 1. Think all proposals suffer from this, why upgrade in the first place - what do the end user gain? It is really hard to find disruptive elements in the proposals 2. Yes, no problem 3. Agree, has been taken into account and obeyed 4. Almost, I do have issues with some applications when it goes outside an ALOC realm 5. Disagree here, both approaches should be adopted because there is the cache issue that is scaring the crap out of me. More about the cache later on. Also other benefits than routing scalability in Internet can be achieved if you take this core-edge split to the hosts' stack. See what Microsoft Research have done with their VL2 work http://research.microsoft.com/pubs/80693/vl2-sigcomm09-final.pdf I'm not working for MS but here is an example what can be done if you don't exclude a host stack upgrade > >> Think we should remove the >> technical nerd hat for a while and put on the shoes of residential >> user and the trousers of a CIO in an enterprise, ask ourselves - do >> our proposals: >> >> - introduce any new services? >> >> - lower the cost of Internet equipment? >> >> - make Internet connectivity more or less complicated? >> >> - can you use any idealistic arguments, e.g. green values, to promote >> a migration? >> >> - introduce some new e.g. API etc that could provide a path to create >> new services on? >> >> These end user do not understand nor cares about routing scalability >> or that the depletion of IPv4 is soon occurring, simply because they >> have a very well working Internet at the moment - they also have a >> valid IP address space and the new address space do not provide any >> new services that can't be found in the current Internet. > > I agree. I think that in order to solve the routing scalability > problem, we need to construct a perfectly beneficial Trojan Horse. > We can generally assume they won't do anything to their networks > purely for the purpose of helping with scalable routing. So we need > to give them something provides concrete and immediate benefits, and > which will also achieve our scalable routing goals if adopted > sufficiently widely. > Yes, and I believe that the Trojan Horse is called MPTCP :-) My guess is that MPTCP offers something interesting for the end-users and we do have an opportunity to smuggle our Achilles in the hosts when MPTCP is getting deployed > The requirements for getting people to adopt the Horse depend on the > nature of the architecture. > > For CES, we only need it to be adopted by the subset of end-user > networks we are trying to serve - those which want or need > portability, multihoming and TE. This is as long as the scheme is > self-contained with its own PTRs (LISP) or DITRs (Ivip). In > practice, it would also be best if networks which weren't using EID > addresses (LISP) or SPI addresses (Ivip) also installed ITRs - since > that would make the whole thing work better than relying on PTRs and > DITRs. > > Still, there is no need, with a CES, to do any of these things: > > 1 - Change host stacks or apps in any hosts whatsoever. > > 2 - Change routers or hosts in any networks not adopting the new > kind of space. > > in order to: > > 1 - Give full portability, multihoming etc. benefits to the > adopting networks. > > 2 - Achieve routing scalability goals in direct proportion to > the number of end-user networks which adopt the system. > > With a CEE, it is totally different. > > As far as I know, no network which adopts it can get portability, > multihoming etc. benefits for all its packets until all other hosts > in the world adopt the system too. > Nope, not true. By using MPTCP you can migrate current multi-homing towards multi-pathing. No tweaking with BGP load-balancing anymore, let the transport protocol take care of the load-balancing and multi-homing. And this can be done in a smooth way, also it should lower the costs of networking devices. It is true that you would need a lot of host stacks to be upgraded before the benefits can be harvested, thus CEE needs a CES solution to speed up the adaption. Then you argue, as you do, that it is sufficient with a CES solution only. But here I see a paradox and I might be wrong, so please correct me if I miss something. The more popular a CES solution becomes the more stress it will create on the ETR (that becomes ITR for returning traffic). If the CES solution becomes popular and gets widely deployed, e.g. if broadband routers will include an ITR stack it will increase cache sizes on the ETRs in front of popular sites. Today broadband address space is quite well aggregated in the DFZ but if you put an ITR on every broadband router the currently aggregated PA-address space will get de-aggregated on the ETRs in front of popular sites. Of course the core network will have a smaller FIB but how large cached FIB is needed on the popular ETRs? One million, two millions, will it scale? What about the housekeeping of the caches? What are the costs of these large cache ETRs - it is not trivial to do housekeeping with two millions cache entries, or is it? Will the content providers adapt to this technology - if the content sites becomes unreliable due to cache housekeeping will they adapt or do they rather stay with the current solution - so they don't risk their business model? If the cache solution is not 100% reliable and proven the content providers will most likely not accept this technology and then the CES approaches will not be adapted. Can you get a better story if you combine a CES with CEE from day one, explaining the benefits of it, also remove the address space constraints, so that the content providers can have simpler&cheaper Internet connectivity and they can reach more customers in the future? Only more questions....and I might misunderstand something... -- patte _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
