Here is the .txt version.
---------- Forwarded message ----------
From: Charrie Sun <charrie...@gmail.com>
Date: 2010/1/19
Subject: Critique of LMS and GLI-Split
To: RRG <rrg@irtf.org>
Hello all,
Since no one has written a critique of my LMS, I queried my workmates
and wrote a critique on it. As many people have pointed out, LMS is a
mapping mechanism and does not itself constitute a whole solution for the
scalability problem. Well the mechanism is based on edge-core separations
and can incorparate with proposals that need a global mapping system,
to enhance its functionalities.
I also wrote a brief critique on GLI-Split, since I think the two
separation planes it clarifies, including the separation between identifier
and locator and the separation between local and global locator, can meet
different needs of ISPs and hosts. I had some discussions with Dr. Menth and
wrote the critique based on the discussions and rethinking. Welcome for
complement and rectifications on mine.
Attached is my critiques and warmly welcome for comments.
Best wishes,
Sun Letong
Critique of GLI-Split, by Sun Letong
GLI-Split makes a clear distinction between two separation planes: the
separation between identifier and locator, which is to meet end-users needs
including mobility; the separation between local and global locator, to make
the global routing table scalable. The distinction is needed since ISPs and
hosts have different requirements.
A main drawback of GLI-Split is that it puts too much burden on hosts. Before
routing a packet received from upper layers, network stacks in hosts firstly
need resolve the DNS name to an IP address; if the IP address is GLI-formed, it
may further map the identifier extracted from the IP address to the local
locator. If the communication is between different GLI-domains, hosts need
further to map the identifier to the global locator, if the local mapping
system does not forward the request to the global mapping system for hosts.
This may lead to large delays and for low-powered hosts it may become
unpractical. For communications spanning GLI-domains, hosts can send packets to
a default GLI-gateway if they receive a negative answer from local mapping
system, and the default GLI-gateway does the identifier-to-global locator
mapping. The author argues that the multiple mapping lookups in hosts is for
them to do multipath routing, since different destinations (local or global)
may need different outgoing gateways. However, the gains of multipath routing
and the cost of host burdens, and the corresponding delays, need to be further
balanced.
GLI-hosts need a home address for mobility. I think thereĄŻs no such need if
the DNS system updates in time when GLI-hosts move across GLI-domains, which is
less frequent compared with host mobility within a GLI-domain. The DNS updates
would not take too long: on one hand, caching time of DNS now is as small as a
few seconds or minutes (for load balance and other applications); on the other
hand, a mechanism can be devised to trigger updates on DNS data. Furthermore,
in this case hosts need not map the identifier to the global locator since the
returned DNS response has that information, of course, if they do not need
multipath routing.
As it claims, the main benefit of GLI-Split is for nodes move within a
GLI-domain, since it would not bother the outside world. When hosts move across
GLI-domain more changes may be needed. And the upgrades on hosts are costly,
while the tradeoff between their gains needs discussion.
Critiques of LMS, by Sun Letong
LMS is a mapping mechanism and based on edge-core separations. In fact, any
proposal that needs a global mapping system with keys of similar properties of
that ¡°edge address¡± in the edge-core separation can use such a mechanism.
This means that those keys are globally unique (by authorization or just
statistically), at the disposal of edge users, and may have several satisfied
mappings (with different weights, maybe). Once a proposal that needs mapping
but doesn't specify the mapping mechanism, is used to solve the scalability
problem, LMS can be used to strengthen its function.
The key idea of LMS is similar to LISP+ALT that the mapping system should be
hierarchically organized, to gain scalability in the storage and update sense
and to achieve quick index for mapping lookup. However, LMS advocates an
ISP-independent mapping system and ETRs are not the authorities of mapping
data. ETRs or edge-sites report their mapping data to related mapping servers.
Though LMS assumes that mapping servers can be incrementally deployed in that a
server may not be constructed if none of its administered edge addresses are
allocated, and that mapping servers can charge for their services, which
provides the economic reason for their existence, how this brand-new system can
be constructed is still not clear. Explicit layering is only an ideal state,
and it rather analyzes the layering limits and feasibility, than provide a
practical way for deployment.
The drawbacks of LMS¡¯s feasibility analysis also include 1) based on current
PC power and may not represent future circumstances (especially for IPv6); 2)
does not consider the variability of address utilization. Some IP address
spaces may be effectively allocated and used while some may not, causing some
mapping servers overloaded while others poorly utilized. More thoughts are
needed as to the flexibility of the layer design.
LMS doesn¡¯t fit well for mobility. It does not solve the problem when hosts
move faster that the mapping updates and propagations between relative mapping
servers. On the other hand, mobile hosts moving across ASes and changing their
attach points (core addresses) is less frequent than hosts moving within an AS.
I personally advocate that separation needs two planes: edge-core separation,
which is to gain routing table scalability; identity-location separation, which
is to achieve mobility. GLI does a good clarification and in that case, LMS can
be used to provide identity-to-core address mapping. Of course, other schemes
may be competent and LMS can be incorporate with it if it has globally seen
keys and needs to map them to other namespaces.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
