Hi Michael: 2010/1/19 Michael Menth <[email protected]>
> Dear Sun Letong, > > Charrie Sun schrieb: > >> Hello Michael, >> Questions are inline. >> 2010/1/19 Michael Menth <[email protected] <mailto: >> [email protected]>> >> >> >> 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. >> >> 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). >> >> 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? > > >> 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. >> >> Well what I mean is that compared with the benefits, the upgrades of >> GLI-hosts are costly. >> >> 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. >> >> I think through this way burdens can be relieved partly from hosts. >> > 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. >> >> 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. >> > 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. > > 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. > >> 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 >> < >> 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>> >> >> >> ). 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. >> > Hm, which question? > > Hm... The above 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/~menth/Publications/papers/Menth-GLI-Split.pdf >> < >> 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>> >> >> >> 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. >> > > Feel free to ask if you have any questions! > > Regards, > > Michael > > > >> 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 protected] >> <mailto:[email protected]> >> http://www3.informatik.uni-wuerzburg.de/research/ngn >> >> >> Thank you for your clarification. >> Best regards, >> Letong >> > > -- > 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 protected] > http://www3.informatik.uni-wuerzburg.de/research/ngn > > Best regards, Leong
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
