Subject: [rrg] Critique of LMS and GLI-Split

From: Charrie Sun <[email-masked]>
Date: Tue, 19 Jan 2010 11:13:17 +0800

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

---

From: Charrie Sun <[email-masked]>
Date: Tue, 19 Jan 2010 11:27:42 +0800

Here is the .txt version.

---------- Forwarded message ----------
From: Charrie Sun <[email-masked]>
Date: 2010/1/19
Subject: Critique of LMS and GLI-Split
To: RRG <[email-masked]>

Hello all,

Best wishes,
Sun Letong

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 19 Jan 2010 00:00:55 -0800

the text version is indeed much better for many people I believe  
(though there still seem some strange char's in the text)

On Jan 18, 2010, at 7:27 PM, Charrie Sun wrote:

> 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.

it seems to me that a major missing issue in LMS critique is an  
articulation on the novelty: given this design is long after LISP-ALT,  
what are the fundamental differences/new gains in LMS?

I read through the paper your summary pointed to (http://www.ietf.org/mail-archive/web/rrg/current/msg05491.html 
).  Section 5 stated that

"The idea is similar to LISP+ALT while differs from it in several ways:
(1) As previous stated we place ETRs at the core, while LISP+ALT  
places them at the edge;
(2) MNs maintain mapping data instead of ETRs.
(3) the structure is explicitly designed as to the layer number and  
node degrees, which is unclear in LISP-ALT.
(4)ITR buffers the arriving packets when its cache failed to find a  
mapping. In LISP+ALT now the implementation is just to drop the  
packets."

None of the above points looks like essential to me.

Wonder what I missed?

Lixia

---

From: Michael Menth <[email-masked]>
Date: Tue, 19 Jan 2010 10:17:34 +0100

Dear Sun Letong,

thanks a lot for writing the critique for GLI-Split. I have some 
clarifying comments, see inline.

> 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.
The distinction makes ISP changes invisible for nodes within a 
GLI-domain including the local mapping system, and structural changes 
inside a GLI-domain invisible to nodes outside a GLI-domain including 
the global mapping system.

> 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. 
1) Upgraded GLI-hosts convert the identifier address either to a local 
or global address. They perform only a single conversion. When reading 
the text one may think that two conversion steps are required.
2) The conversion usually does not introduce a "large dealy" as the 
mapping infos are cached. The delay is at the host where it is not 
critical. It's like DNS lookup, probably faster if the mapping system is 
more efficient than DNS (see FIRMS).
3) This statement suggests that GLI-Split requires host changes which is 
not necessarily true. A major objective of GLI-Split is to be 
backward-compatible. That means, GLI-domains can accommodate upgraded 
GLI-hosts and classic IPv6 hosts for which no changes are necessary. Of 
course, upgraded GLI-hosts enjoy more benefits than classic IPv6 hosts. 
This essential aspect is lacking.

> 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. 
That's part of the description. I cannot see how this sentence is 
related to the previous or next statement.

> 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-Split does not mandate multipath routing but it supports it if 
needed. And there is a clear desire to support multipath routing, just 
see the current efforts in IETF for multipath TCP.

> 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.
We deliberately left out the description of this mechanism because we 
think that it is a substitute to mobile IP and orthogonal to most 
routing and addressing approaches. You could introduce that already in 
today's Internet. In contrast, GLI-Split provides a different substitute 
for mobile IP which does not interact with DNS for the change of the 
location (see Section 3.7 in 
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth-GLI-Split.pdf 
). It is applicable only if  two GLI-hosts communicate with each other 
as this mechanism does depend on the specific routing and addressing 
architecture.

> 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.
GLI-domains can accommodate upgraded and classic IPv6 hosts and the 
latter do not need any upgrade. This was a major design goal to avoid 
costly upgrades which can be an obstacle for deployment. The benefits of 
GLI-Split are summarized in Section 5 of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth-GLI-Split.pdf
Some of them are available only for upgraded hosts, others also for 
classic hosts.

Kind regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Charrie Sun <[email-masked]>
Date: Tue, 19 Jan 2010 17:37:15 +0800

---------- Forwarded message ----------
From: Charrie Sun <[email-masked]>
Date: 2010/1/19
Subject: Re: [rrg] Fwd: Critique of LMS and GLI-Split
To: Lixia Zhang <[email-masked]>

Hi Lixia,
  I think the biggest difference between LISP+ALT and LMS is that mapping
nodes in LMS are not only indexing nodes but also the final authorities of
mapping data. This correlates tightly with the question that whether the
separation should be placed at the core or the edge. In LISP separation work
in at the edge to facilitate TE etc, thus letting ETRs to be the mapping
authorities would not bring so many problems as those in the cores doing
separation. Since in the latter case, if an edge is multihomed to several
ISPs and thus connects to ETRs at different ISPs, no ETR would like to store
mapping data for its customer and its opponents. However, routers in edge
networks may often not hold a whole global routing table and they set
default route to their providers to reach the outside world, thus I assume
they may not see the scalability problem that serious as core routers. In
this sense, edge routers may not have much incentives to upgrade, to be
ITRs and ETRs.
   In LMS the mapping system is independent of ISPs and they charge for
their mapping services, forming a new interest group. ISPs as well as edge
networks whole join the circle can benefit immediately with few changes
(core routers may do tunneling, edge networks need no changes while they are
willing to inform mapping information to the mapping system to realize TE).
I mainly concerned the economic model here.
   Compared with ALT, I think we only share the hierarchical struture, while
the content the mapping system holds and the economic model is different.
    Thank you very much for your opinions!

Best wishes,
Letong

2010/1/19 Lixia Zhang <[email-masked]>

the text version is indeed much better for many people I believe (though
> there still seem some strange char's in the text)
>
>
>
>> and can incorparate with proposals that need a global mapping system, to
>> enhance its functionalities.
> articulation on the novelty: given this design is long after LISP-ALT, what
> are the fundamental differences/new gains in LMS?
>
> I read through the paper your summary pointed to (
> http://www.ietf.org/mail-archive/web/rrg/current/msg05491.html).  Section
> 5 stated that
>
> (1) As previous stated we place ETRs at the core, while LISP+ALT places
> them at the edge;
> (3) the structure is explicitly designed as to the layer number and node
> degrees, which is unclear in LISP-ALT.
> mapping. In LISP+ALT now the implementation is just to drop the packets."
>

---

From: Charrie Sun <[email-masked]>
Date: Tue, 19 Jan 2010 18:23:13 +0800

Hello Michael,
  Questions are inline.
2010/1/19 Michael Menth <[email-masked]>

> Dear Sun Letong,
>
> thanks a lot for writing the critique for GLI-Split. I have some clarifying
> comments, see inline.
>
>> 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.
>>
> The distinction makes ISP changes invisible for nodes within a GLI-domain
> including the local mapping system, and structural changes inside a
> GLI-domain invisible to nodes outside a GLI-domain including the global
> mapping system.
>
>> 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.
>>
> 1) Upgraded GLI-hosts convert the identifier address either to a local or
> global address. They perform only a single conversion. When reading the text
> one may think that two conversion steps are required.
>

Did I miss something, but in the section of communications between different
GLI-Domains (section 3.1.2), it is said that when GLI-node queries local
mapping system and get a negative answer, it queries the global mapping
system. Local mapping system forward the request for GLI-nodes to the global
MS is just an option.

> 2) The conversion usually does not introduce a "large dealy" as the mapping
> infos are cached. The delay is at the host where it is not critical. It's
> like DNS lookup, probably faster if the mapping system is more efficient
> than DNS (see FIRMS).
>

Cache cannot solve the problem of "first-packet-delay". And in IPv6,
storing location information of all mapping servers (considering the huge
indexing space) like FIRMS is unscalable.

> course, upgraded GLI-hosts enjoy more benefits than classic IPv6 hosts. This
> essential aspect is lacking.
>
> Well what I mean is that compared with the benefits, the upgrades of
GLI-hosts are costly.

>> 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.
>>
> That's part of the description. I cannot see how this sentence is related
> to the previous or next statement.
>
>
I think through this way burdens can be relieved partly from hosts.

> 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-Split does not mandate multipath routing but it supports it if needed.
> And there is a clear desire to support multipath routing, just see the
> current efforts in IETF for multipath TCP.
>
>
Ok, further reflection is needed on the balance between application needs
and corresponding costs.

> 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.
>>
> We deliberately left out the description of this mechanism because we think
> that it is a substitute to mobile IP and orthogonal to most routing and
> addressing approaches.

I cannot catch up with this sentence, and I cannot see why the mechanism is
not beneficial. By updating the DNS data, home-address is unneeded, no
matter for communications between GLI-nodes and between GLI-hosts and
classic IPv6 hosts.

> You could introduce that already in today's Internet. In contrast,
> GLI-Split provides a different substitute for mobile IP which does not
> interact with DNS for the change of the location (see Section 3.7 in
> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth-GLI-Split.pdf). It is applicable only if  two GLI-hosts communicate with each other as
> this mechanism does depend on the specific routing and addressing
> architecture.
>
>
Question remains as before.

>> 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.
>>
> GLI-domains can accommodate upgraded and classic IPv6 hosts and the latter
> do not need any upgrade. This was a major design goal to avoid costly
> upgrades which can be an obstacle for deployment. The benefits of GLI-Split
> are summarized in Section 5 of
>
> Some of them are available only for upgraded hosts, others also for classic
> hosts.
>
>
I think I will learn more about the GLI's benefits on backward
compatibility, which I underestimated before.

>   Michael
Thank you for your clarification.

Best regards,
Letong

---

From: Michael Menth <[email-masked]>
Date: Tue, 19 Jan 2010 12:10:42 +0100

Dear Sun Letong,

Charrie Sun schrieb:
> Hello Michael,
>   Questions are inline.
> 2010/1/19 Michael Menth <[email-masked] 
> <mailto:[email-masked]>>
>
>     Dear 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.
>
>     GLI-domain including the local mapping system, and structural
>     changes inside a GLI-domain invisible to nodes outside a
>     GLI-domain including the global mapping system.
>
>         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
>     1) Upgraded GLI-hosts convert the identifier address either to a
>     local or global address. They perform only a single conversion.
>     When reading the text one may think that two conversion steps are
>     required.
>
>  
> Did I miss something, but in the section of communications between 
> different GLI-Domains (section 3.1.2), it is said that when GLI-node 
> queries local mapping system and get a negative answer, it queries the 
> global mapping system. Local mapping system forward the request for 
> GLI-nodes to the global MS is just an option.
There may be two mapping lookups but only one conversion from identifier 
address to either local or global identifier.

>  
>
>     2) The conversion usually does not introduce a "large dealy" as
>     the mapping infos are cached. The delay is at the host where it is
>     not critical. It's like DNS lookup, probably faster if the mapping
>     system is more efficient than DNS (see FIRMS).
>
>  
> storing location information of all mapping servers (considering the 
> huge indexing space) like FIRMS is unscalable.
The first-packet-delay in hosts is not crucial as packets do not need to 
be stored in intermediate nodes. Describing it as "large delay" sounds 
like tremendously worse than DNS-lookup delay which is rather of the 
same quality.

>  
>
>     3) This statement suggests that GLI-Split requires host changes
>     which is not necessarily true. A major objective of GLI-Split is
>     to be backward-compatible. That means, GLI-domains can accommodate
>     upgraded GLI-hosts and classic IPv6 hosts for which no changes are
>     necessary. Of course, upgraded GLI-hosts enjoy more benefits than
>     classic IPv6 hosts. This essential aspect is lacking.
>
>         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.
>
Unburdening intermediate hosts is more important than unburdening hosts 
as they have time to do lookup operations etc. without storing packets. 
If you want, you can mention the contrary. GLI-gateways need to 
substitute local source addresses by global source addresses, but a 
lookup is not required for that operation.

>  
>
>         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.
>
>     needed. And there is a clear desire to support multipath routing,
>     just see the current efforts in IETF for multipath TCP.
>
>  
> Ok, further reflection is needed on the balance between application 
> needs and corresponding costs.
As I said, the mechanisms adds more complexity only if it is used in 
case it is needed. Potential multipath support should not be viewed as a 
disadvantage!

>  
>
>         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.
>
>     We deliberately left out the description of this mechanism because
>     we think that it is a substitute to mobile IP and orthogonal to
>     most routing and addressing approaches. 
>
>  
> I cannot catch up with this sentence, and I cannot see why the 
> mechanism is not beneficial. By updating the DNS data, home-address is 
> unneeded, no matter for communications between GLI-nodes and between 
> GLI-hosts and classic IPv6 hosts.
Let me try again. Updating DNS with the current location instead of 
using mobile IP is a general mechanism which could be done whenever DNS 
is in use - actually even today (but it's not of course!). This feature 
can be easily added to any architecture because it does not really 
depend on it. It can also be added to GLI-Split if it is desired. Your 
mentioned mechanism depends on how fast DNS can be updated. In the 
GLI-Split paper, we propose an alternative mechanism for GLI-hosts that 
bypasses DNS.

>     GLI-Split provides a different substitute for mobile IP which does
>     not interact with DNS for the change of the location (see Section
>     3.7 in
>     <http://www3.informatik.uni-wuerzburg.de/%7Ementh/Publications/papers/Menth-GLI-Split.pdf>
>     ). It is applicable only if  two GLI-hosts communicate with each
>     other as this mechanism does depend on the specific routing and
>     addressing architecture.
>
>  
Hm, which question?

>  
>
>
>         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.
>
>     GLI-domains can accommodate upgraded and classic IPv6 hosts and
>     the latter do not need any upgrade. This was a major design goal
>     to avoid costly upgrades which can be an obstacle for deployment.
>     The benefits of GLI-Split are summarized in Section 5 of
>     <http://www3.informatik.uni-wuerzburg.de/%7Ementh/Publications/papers/Menth-GLI-Split.pdf>
>     Some of them are available only for upgraded hosts, others also
>     for classic hosts.
>
>  

Feel free to ask if you have any questions!

Regards,

    Michael

>     <mailto:[email-masked]>

---

From: Charrie Sun <[email-masked]>
Date: Tue, 19 Jan 2010 19:53:05 +0800

Hi Michael:

> Dear Sun Letong,
>
> Charrie Sun schrieb:
>
>> Hello Michael,
>>  Questions are inline.
>> 2010/1/19 Michael Menth <[email-masked] <mailto:
>> [email-masked]>>
>>
>>
>>    Dear Sun Letong,
>>
>> different GLI-Domains (section 3.1.2), it is said that when GLI-node queries
>> local mapping system and get a negative answer, it queries the global
>> mapping system. Local mapping system forward the request for GLI-nodes to
>> the global MS is just an option.
>>
> The first-packet-delay in hosts is not crucial as packets do not need to be
> stored in intermediate nodes. Describing it as "large delay" sounds like
> tremendously worse than DNS-lookup delay which is rather of the same
> quality.
>
>
It is no worse than DNS-lookup in general, but the delay itself would be
troublesome. I do not understand why the first-packet-delay is not crucial
for hosts. Why because of that packets not need to be stored in intermediate
nodes? If the end host itself buffer the packets whose mapping is
unresolved, large delay would lead waiting packets overflow the buffer; if
it does not, large delay may cause packet loss. Is it not important?

> Unburdening intermediate hosts is more important than unburdening hosts as
> they have time to do lookup operations etc. without storing packets. If you
> want, you can mention the contrary. GLI-gateways need to substitute local
> source addresses by global source addresses, but a lookup is not required
> for that operation.
>
>
>

> As I said, the mechanisms adds more complexity only if it is used in case
> it is needed. Potential multipath support should not be viewed as a
> disadvantage!
>
>
>
>>  I cannot catch up with this sentence, and I cannot see why the mechanism
>> is not beneficial. By updating the DNS data, home-address is unneeded, no
> Let me try again. Updating DNS with the current location instead of using
> mobile IP is a general mechanism which could be done whenever DNS is in use
> - actually even today (but it's not of course!). This feature can be easily
> added to any architecture because it does not really depend on it. It can
> also be added to GLI-Split if it is desired. Your mentioned mechanism
> depends on how fast DNS can be updated. In the GLI-Split paper, we propose
> an alternative mechanism for GLI-hosts that bypasses DNS.
>
> I think that updating DNS would make home-address unneeded, and more
importantly, hosts may resolve the domain name and get the GLI address which
already contains the valid global locator, and hosts need not query the
global mapping system for that information once more.

>>    <
>> http://www3.informatik.uni-wuerzburg.de/%7Ementh/Publications/papers/Menth-GLI-Split.pdf<http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth-GLI-Split.pdf>>
>>
>>
> Hm... The above question.

>>    <
>> http://www3.informatik.uni-wuerzburg.de/%7Ementh/Publications/papers/Menth-GLI-Split.pdf<http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth-GLI-Split.pdf>>
>>
>>
>>    --    Dr. Michael Menth, Assistant Professor

Best regards,
Leong

---

From: Michael Menth <[email-masked]>
Date: Tue, 19 Jan 2010 13:47:39 +0100

Dear Sun Letong,

Charrie Sun schrieb:
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>
>            Dear Sun Letong,
>
>                lead to large delays and for low-powered hosts it may
>         become
>                unpractical.
>
>          Did I miss something, but in the section of communications
>         between different GLI-Domains (section 3.1.2), it is said that
>         when GLI-node queries local mapping system and get a negative
>         answer, it queries the global mapping system. Local mapping
>         system forward the request for GLI-nodes to the global MS is
>         just an option.
>
>     There may be two mapping lookups but only one conversion from
>     identifier address to either local or global identifier.
>
>
>          
>          Cache cannot solve the problem of "first-packet-delay". And
>         in IPv6, storing location information of all mapping servers
>         (considering the huge indexing space) like FIRMS is unscalable.
>
>     The first-packet-delay in hosts is not crucial as packets do not
>     need to be stored in intermediate nodes. Describing it as "large
>     delay" sounds like tremendously worse than DNS-lookup delay which
>     is rather of the same quality.
>
>  
> It is no worse than DNS-lookup in general, but the delay itself would 
> be troublesome. I do not understand why the first-packet-delay is not 
> crucial for hosts. Why because of that packets not need to be stored 
> in intermediate nodes? If the end host itself buffer the packets whose 
> mapping is unresolved, large delay would lead waiting packets overflow 
> the buffer; if it does not, large delay may cause packet loss. Is it 
> not important?
When intermediate nodes need perform a mapping lookup, there are three 
different options for the packets:
1) discard it (undesired)
2) queue it (though buffer overflow can occur which is a way for new 
attacks)
3) forward it, e.g., over the mapping system (more complex)
This problem is avoided when mapping lookups are performed by the hosts 
instead of intermediate nodes.

>         Well what I mean is that compared with the benefits, the
>         upgrades of GLI-hosts are costly.
>          
>     Unburdening intermediate hosts is more important than unburdening
>     hosts as they have time to do lookup operations etc. without
>     storing packets. If you want, you can mention the contrary.
>     GLI-gateways need to substitute local source addresses by global
>     source addresses, but a lookup is not required for that operation.
>
>
>  
>
>
>          
>          Ok, further reflection is needed on the balance between
>         application needs and corresponding costs.
>
>     As I said, the mechanisms adds more complexity only if it is used
>     in case it is needed. Potential multipath support should not be
>     viewed as a disadvantage!
>
>
>          
>          I cannot catch up with this sentence, and I cannot see why
>         the mechanism is not beneficial. By updating the DNS data,
>         home-address is unneeded, no matter for communications between
>         GLI-nodes and between GLI-hosts and classic IPv6 hosts.
>
>     Let me try again. Updating DNS with the current location instead
>     of using mobile IP is a general mechanism which could be done
>     whenever DNS is in use - actually even today (but it's not of
>     course!). This feature can be easily added to any architecture
>     because it does not really depend on it. It can also be added to
>     GLI-Split if it is desired. Your mentioned mechanism depends on
>     how fast DNS can be updated. In the GLI-Split paper, we propose an
>     alternative mechanism for GLI-hosts that bypasses DNS.
>
> importantly, hosts may resolve the domain name and get the GLI address 
> which already contains the valid global locator, and hosts need not 
> query the global mapping system for that information once more.
Home addresses are still required for interoperability with legacy 
systems. Therefore, you cannot completely renounce on the maintenance of 
home addresses if you want to communicate with legacy.

Best wishes,

    Michael

>          I think I will learn more about the GLI's benefits on
>         backward compatibility, which I underestimated before.
>
>
>            <mailto:[email-masked]

---

From: Charrie Sun <[email-masked]>
Date: Wed, 20 Jan 2010 11:49:44 +0800

I revised my critique about GLI-Split, after the discussion with Dr. Menth
and have some new understanding on the proposal. Appreciate more
for comments and revisions.

Best wishes,
Letong

---

From: Charrie Sun <[email-masked]>
Date: Wed, 20 Jan 2010 11:51:12 +0800

Sorry, the .txt version.

---------- Forwarded message ----------
From: Charrie Sun <[email-masked]>
Date: 2010/1/20
Subject: Re: [rrg] Fwd: Critique of GLI-Split
To: [email-masked], RRG <[email-masked]>

Best wishes,
Letong

---

From: Charrie Sun <[email-masked]>
Date: Thu, 21 Jan 2010 12:12:46 +0800

Hello all,

Based on some discussions (on the list or privately), I revised my critique
on GLI-Split. Warmly welcome for any critiques and revisions.

Best wishes,
Letong

---

From: Tony Li <[email-masked]>
Date: Wed, 20 Jan 2010 10:24:28 -0800

Charrie Sun wrote:
> I revised my critique about GLI-Split, after the discussion with Dr. 
> Menth and have some new understanding on the proposal. Appreciate more 

Received and incorporated.

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 21 Jan 2010 01:24:39 -0800

Charrie Sun wrote:
> 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. 

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 21 Jan 2010 01:28:15 -0800

Charrie Sun wrote:
>  
> Hello all,
>  
> Based on some discussions (on the list or privately), I revised 
> my critique on GLI-Split. Warmly welcome for any critiques and revisions.

Tony