Short versions: CEE and CES architectures are vastly
different in how benefit arises from effort.
With CES, end-user networks get instant full
benefits and routing scaling benefits are in
direct proportion to how many such end-user
networks adopt it.
With CEE, there's no really usable set of
benefits for end-user networks until pretty
much all the hosts in the Net adopt the CEE
upgrades too. Only then can there be any
real routing scaling benefits.
ASCII art diagrams of the cumulative
effort -> benefit relationships for CES
and CEE.
Hi patte,
Thanks for your response:
> Robin,
>
> think I need to speak up and comment on a few things.
>
>> 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
I am not suggesting that if someone wants to implement a host-based
CEE approach that they should be prevented from doing so - nor are
you implying that I did.
>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.
It is reasonable to assume that every end-user network (which wants
or needs portability, multihoming etc.) which we need to adopt a
scalable solution will require continual uninterrupted communications
with all hosts, including those which have no adopted the new system.
We need the great majority of these networks to adopt a scalable
solution, because there are believed to be so many of them (millions
to ten million I guess) that even a small number using conventional
PI space threatens the scalability of the DFZ.
With this assumption, and with the assumption that multihoming for
only a subset of sessions is of no real value, then point 1 can't
happen unless all the hosts on the Net adopt the new system - because
ordinary hosts can't communicate with (or at least initiate
communications with) this networks' hosts via their new edge
identities (which is the only way the adopting network's hosts can be
reached once they no longer have PI space).
Even if the end-user network was ready to accept 10% of hosts not
being able to reach their hosts, which seems unlikely, this means
such networks can only give up their PI space once 90% of the hosts
in the world adopt the same system.
Perhaps I am mistaken in assuming these things about CEE systems -
there are quite a few of them and I am yet to read those proposals in
detail.
So, from the point of view of routing scalability, I don't see the
point in encouraging end-user networks to adopt CEE unless we could
be confident that everyone would adopt it. As far as I know,
networks can only switch of their PI space, or get truly usable
portability, multihoming etc. when essentially all other hosts are
using the same system.
>> 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.
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.
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.
There may be CEE architectures which work entirely with existing API
and applications, but I can't think of one now that would work.
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.
>> 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.
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.
> 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.
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.
As far as I know, no network would find these benefits of any real
use unless they applied to all, or almost all (~99%+), their
communications.
As far as I know, there's no way any end-user network with PI space
would abandon it, and so provide scalable routing benefits, until
almost all their communications were with upgraded hosts.
Here are some ASCII art diagrams for the scalable routing benefit vs.
effort curves for the two types of proposal:
^
B | * Core-Edge Separation (CES)
e | **
n | ***
e | ****
f | *****
i | ******
t | *******
| ********
|*********
0--------->
Effort ~= level of adoption
^
B | * Core-Edge Elimination (CEE)
e | *
n | * (IPv6 adoption too.)
e | *
f | *
i | *
t | *
| *
|*********
0--------->
Effort ~= level of adoption
CEE gives no really usable benefits to adopters until all other
networks adopt it. There are no scalable routing benefits until
firstly these really usable benefits exist and secondly, this enables
those with PI space to release it.
So our CES-style Trojan Horse is a lot easier to get people to adopt,
since it provides them with immediate benefits, irrespective of the
rate of adoption - and it produces scalable routing benefits to the
exact degree to which it is adopted.
A CEE Trojan Horse is not going to be widely enough adopted to ever
reach the required nearly 100% adoption rates, because it takes
effort, eats hay etc. and doesn't do anything really useful until
everyone in the Net, every host, adopts it as well.
> And of course you, put also on the shirt of an ISP and ask the same questions
Indeed. As far as I know, the only possible conclusion is that the
best CES architecture could be adopted widely, and that even the best
CEE architecture (in terms of scalable routing benefits, or benefits
to adopters once everyone else adopts it) would be impossible to have
adopted by more than a tiny fraction of networks.
>> 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?
HIP is a CEE and it uses crypto, but perhaps it is optional:
http://tools.ietf.org/html/rfc4423
I intend to look more closely at the CEE RRG proposals to see what
they require of hosts. I think many of them involve nonces, which is
not such a problem.
> We are trying to remove the IP address overload (identifier and
> locator)
Not me - Ivip and other Core-Edge Separation architecture still
retain the IP address as both the identifier and locator for each
host. Its just that a subset of the address space (SPI for Ivip, EID
for LISP) is interpreted differently by special devices (ITRs) which
are able to get the packets to ETRs anywhere in the Net. So for SPI
space, the actual IP address doesn't imply anything about where the
destination host is. Nonetheless, it is still used by the routing
system to get the packet to its destination. Its just that ITRs and
the mapping system are more flexible and scalable than the BGP DFZ's
way of deciding where to send the packet.
> 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.
As far as I know, a CEE converted host doesn't derive any benefits of
portability, multihoming etc. with packets arriving from a non-CEE
host. So if you want all your traffic to be portable, multihomable
(which I assume any network would require before they considered the
thing at all useful) then this is only going to happen once all other
hosts in the world are upgraded too.
> 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.
The only way I know of doing mobility, without service interruption
every time the MN gets a new address, is my TTR Mobility approach:
http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf
This requires a CES architecture, but doesn't require mapping changes
every time the host gets a new address. It would work for IPv4 and
IPv6, enable communication with normal protocols to all other hosts,
and enable the host to be behind one or more layers of NAT. This
would provide the MN with one or more IPv4 addresses or IPv6 /64
prefixes no matter where it was, with generally optimal paths. It
requires infrastructure in the network itself, but not in the access
networks. I think this could be a commercially feasible and
attractive service.
> I think MPTCP, http://tools.ietf.org/html/draft-ford-mptcp-multiaddressed-02,
> doesn't add that much overhead
But that requires host stacks at both ends be upgraded and that the
applications are written to use MPTCP. I am not sure how well it
would work with a host which could be connected to any address,
including behind NAT. MPTCP is probably not much good for VoIP,
streaming media or other protocols which naturally work well with UDP.
> 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
I think extending a scalable routing CES system with TTRs
(Translating Tunnel Routers), or building a CES system just for the
TTR system would both work fine - and the only host changes would be
some extra software for tunneling and a few other things in the MN
itself.
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
