Robin, think I need to speak up and comment on a few things.
On Fri, Jan 22, 2010 at 3:52 AM, Robin Whittle <r...@firstpr.com.au> wrote: > Tony - as far as I know, you are opposed to CES (Core-Edge > Separation) and in favour of CEE (Core-Edge Elimination). > > 5 or 6 full proposals are CEE and only 4 are CES (LISP, Ivip, TIDR > and RANGER) - so it seems that many active RRG folks fully support > CEE in favor of CES. Believe we need both CEE and CES so that the end users can decide which way to go, either by upgrading the hosts or add a network device in front of their hosts - both approaches should be promoted, and perhaps some additional as well > > The "simple network, sophisticated hosts" paradigm works well in many > respects and I understand there is a perception of elegance in CEE - > which extends this principle further to get hosts to do more routing > and addressing work so the routing system can remain simple. > > Introduction of CEE would involve new host protocols and usually new > application code and APIs in order that hosts and networks can have > multihoming TE, portability (of their identifiers) and probably > mobility - while operating entirely from potentially unstable PA > addresses obtained from their one or more ISPs. (In some schemes, > the ISP's address space only forms the more significant bits of the > host's PI address.) Totally new host protocols might not be needed, you could get around most of the challenges by adding extensions to existing protocols. > > Routing scalability is achieved by way of the DFZ routers only having > to cope with the prefixes of ISPs - not of any end-user networks. > > I hope CEE supporters will argue their case explicitly. My support > for CES is stated fully in section 4.1 of the Ivip-arch ID. > > I think CEE's attraction is based on an over-simplified notion of the > Internet: a routing system with hosts neatly arranged around the > edge. If I thought this was the reality, I would agree that CEE is > the optimal approach - though I would still have no idea how we could > change to CEE on a voluntary basis from the current arrangement. > The voluntary basis issue is the hardest one to crack, it is a valid statement for both CEE and CES proposals. 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. And of course you, put also on the shirt of an ISP and ask the same questions > However, the Internet's routing system is big and has traffic costs, > delays and risks of lost packets. > > Furthermore, an increasing number of hosts are on slow, > less-reliable, and sometimes expensive wireless links. These > problems are fundamental - most wireless links will never be like > fibre or DSL because the spectrum is shared, the base-stations and > mobile devices are interfering with each other, the timeslots take > time come around and because upstream capacity usually has to be > reserved in advance. > > An increasing number of hosts have computational constraints due to > being hand-held devices with very limited battery power. This is no > problem for simple protocols and caching a few things, but if > cryptographic work is required in the CEE protocols, then I think it > is more of a problem. I agree here, do we really need to have cryptographic solution on the network layer? We are trying to remove the IP address overload (identifier and locator) but if we are not careful we could introduce some other overload mechanism that somebody has to deal with in the future. The transport layer can take care of things and also the application layer can take care of things, such as cryptographic > > I believe the optimal arrangement for the Internet is not the CEE > approach of requiring *all* hosts to take on more responsibilities > for routing and addressing - which generally involves more state, > more computation, delays in initiating contact with other hosts and > the sending and receiving more and/or longer packets. It also > involves a lot of extra work, packets and therefore delays whenever > the host gets a different (physical, "locator") address. This can > happen frequently with wireless mobile devices, even when they are > stationary. > Not *all* host needs to be upgraded, you could design the architecture in a such way that it is backwards compatible and only part of them needs to be upgraded. But there is price, you have to change the IP address allocating policy and that could be a difficult hurdle. If the host mobility is solved on the network layer it could get complicated as you describe above. I think the host mobility is an issue for the transport protocol - if we are trying to solve that on the network layer IMHO we are overloading the transport and network layer. I think MPTCP, http://tools.ietf.org/html/draft-ford-mptcp-multiaddressed-02, doesn't add that much overhead Yes, the mobile host-to-host rendezvous mechanism is not provided by MPTCP but that can you find on the application layer. For real time applications there is already SIP registrar/proxy in place, peer-to-peer applications have their own solutions etc. Do we need to overload the application and network layer? -- patte > These things might be tolerable and desirable if the Internet's core > had no delays or other costs, and if all hosts were on fast, > inexpensive links and had plenty of CPU power. But CEE generally > causes more delays even with hosts on fast links, due to the extra > work they need to do to be sure of the identity of the other hosts > they are communicating with and the fact that the lookups and > management packets frequently encounter delays in the core, due to > the size of the Earth and the speed of light in SiO2. > > I think CEE would cause unacceptable performance problems and higher > costs for wireless mobile devices - since extra management traffic > has to flow back and forth along this slow and perhaps unreliable > link, frequently before real host-to-host communications begin. IPv6 > makes such management packets longer still. > > Some systems CEE architectures involve adding extra stuff to traffic > packets, at least for some packets. This is further burden on > devices relying on wireless links. > > In the future, I think we should expect that most hosts are going to > be wireless mobile devices. > > I support the CES approach of retaining the existing host protocols > and instead adding things to the network (ITRs, ETRs, mapping system > etc.) to solve the scaling problem and provide mobility. > > > My arguments for Core-Edge Separation are in section 4.1: > > http://tools.ietf.org/html/draft-whittle-ivip-arch#section-4.1 > > > Tony - the reason I think you support CEE is this message from mid-2008: > > http://lists.arin.net/pipermail/arin-ppml/2008-June/010988.html > > Please, please, please go read GSE. You may not like it, you > may not agree with it, but until you grok it, you haven't seen > a big chunk of the solution space. > > and because I don't recall you writing anything in support of LISP, > Ivip or any other CES proposal. > > In the next few weeks I hope to analyse each of the CEE proposals in > detail, to determine to what extent my critique about extra delays, > extra packets etc. applies to them. > > - Robin > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
