It's OK, Thanks!
Yanyyang ----- Original Message ----- From: "Tony Li" <tony...@tony.li> To: "Yangyang Wang" <wyyst...@gmail.com> Cc: "Lixia Zhang" <li...@cs.ucla.edu>; <rrg@irtf.org> Sent: Monday, March 08, 2010 5:04 PM Subject: Re: [rrg] Rebuttal for NOL // Re: NOL (Name Overlay) alternative critique > > > Hi, > > Thanks, that's much closer. I removed the paragraph numbers and > incorporated this. Is that ok? > > Thanks, > Tony > > > > On 3/8/10 12:29 AM, "Yangyang Wang" <wyyst...@gmail.com> wrote: > >> Hi, Tony and Lixia >> >> Sorry. The following is the organized rebuttal for NOL proposal, and about >> 397 >> words. Is this format ok? >> >> ========================= >> 1) NOL resembles neither CEE or CES as a solution. With supporting >> application level session by name overlay, NOL can support some solution >> of style of CEE. NOL is closer to the way of CES, i.e., preventing PI >> prefixes of edge networks from entering into the upstream transit >> networks.This is done by NTR, like the ITR/ETRs in CES, but NOL has >> no need to define the clear boundary between core and edge networks. >> NOL is designed to try to provide end users or networks a service that >> faciliates the adoption of multihoming, multipath routing and traffic >> engineering by the indirect routing through NTRs, and, in the mean time, >> doesn't accelarate, or decrease, the growth of global routing table size. >> >> >> 2) Some problems are stated in the NOL critique. In the original NOL >> proposal document, DNS query for a host that is behind a NTR will >> induce the return of the actual IP addresses of the host and the address of >> the NTR. This arrangement might cause some difficulties for the legacy >> application due to the non-standard response request for DNS. To >> resolve this problem, we can make NOL service use a new namespace, >> and DNS not return NTR IP address for the legacy hosts. The names used >> for NOL is formatted like email addresses, such as "d...@domain.net". >> The mapping between "domain.net" and IP address of corresponding NTR >> will be registered in DNS. NOL layer understand the meaning of the name >> "d...@domain.net" , and it will send a query to DNS only for "domain.net". >> And then, DNS will return IP addresses of the corresponding NTRs. For >> the legacy applications, they will still use the traditional FQDN name and >> DNS will return the actual IP address of the host. However, if the host is >> behind a NTR, the legacy applications may be unable to access the host. >> >> >> 3) The stateless address translation or stateful address and port translation >> maybe cause a scaling problems for the limitiations of the number of table >> entries NTR must maintain. And the legacy applications can not initiate >> sessions with hosts inside the NOL-adopting EUN. However, these >> problems may not be the big barrier for the deployment of NOL or other >> similar approaches. Many NAT-like boxes and proxy and firewall devices >> are widely used at the Ingress/Egress points of Enterprise networks, >> campus networks or other stub EUNs.The hosts running as servers can be >> deployed outside NTRs or be assigned PA addresses in a NTR-adopting >> EUN. >> >> >> >> >> ----- Original Message ----- >> From: "Tony Li" <tony...@tony.li> >> To: "Yangyang Wang" <wyyst...@gmail.com> >> Cc: "Lixia Zhang" <li...@cs.ucla.edu> >> Sent: Monday, March 08, 2010 3:38 AM >> Subject: Re: [rrg] Rebuttal for NOL // Re: NOL (Name Overlay) alternative >> critique >> >> >>> >>> Hi, >>> >>> Thanks for your contribution, but this format makes it difficult for me to >>> incorporate into the document. If your intent was to submit this for >>> inclusion, could you please organize in a way that would be similar to the >>> document? >>> >>> Thanks, >>> Tony >>> >>> >>> >>> On 3/7/10 5:42 AM, "Yangyang Wang" <wyyst...@gmail.com> wrote: >>> >>>> Thanks Robin for your critique, which is helpful for us to review and >>>> improve >>>> the design of NOL. >>>> The rebuttal for NOL is stated in the following. >>>> >>>> ----- Original Message ----- >>>> From: "Robin Whittle" <r...@firstpr.com.au> >>>> To: "RRG" <rrg@irtf.org> >>>> Cc: "Yangyang Wang" <wyyst...@gmail.com> >>>> Sent: Thursday, February 18, 2010 6:02 PM >>>> Subject: NOL (Name Overlay) alternative critique >>>> >>>> >>>>> This is an alternative to the critique of NOL which is in the RRG Report >>>>> ID: >>>>> >>>>> http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04 >>>>> >>>>> and which was written by one of the NOL designers, Yangyang Wang on >>>>> 2010-01-15: >>>>> >>>>> http://www.ietf.org/mail-archive/web/rrg/current/msg05658.html >>>>> >>>>> This is 1088 words. I will refine it with feedback from the designers >>>>> and will include it in the forthcoming omnibus of RRG critiques which >>>>> are not fully included in the final RRG report (draft-whittle-rrg- >>>>> critiques). >>>>> >>>>> The proposal summary and PDF documentation is: >>>>> >>>>> http://www.ietf.org/mail-archive/web/rrg/current/msg05532.html >>>>> >>>>> The RRG Report ID does not currently mention the PDF files which are >>>>> attached to the msg05532. I think it would be good to place them on a >>>>> reasonably permanent site somewhere so references to these could be >>>>> added to the RRG Report. >>>>> >>>>> I previously wrote that I thought NOL was a CEE architecture. I >>>>> currently think it does not resemble either a CEE or CES architecture. >>>>> >>>>> I do not consider NOL to be a viable solution to the routing scaling >>>>> problem. Nonetheless, it is part of the design process and uses a novel >>>>> combination of techniques which have some advantages: no need to alter >>>>> host stacks, or to introduce a new mapping system. >>>>> >>>>> - Robin >>>>> >>>>> >>>>> >>>>> NOL (Name Overlay) alternative critique >>>>> --------------------------------------- >>>>> >>>>> NOL is attempt to solve, or contribute to the solution of, the routing >>>>> scaling problems for both IPv4 and IPv6. NOL's NAT-like architecture >>>>> and enhancements to applications resembles neither that of a Core-Edge >>>>> Elimination (CEE) or Core-Edge Separation (CES) architecture. It >>>>> appears to be inadequate as a solution on its own, and while it is >>>>> intended to be able to be used with either a CES or CEE architecture, it >>>>> is not clear what benefits NOL would bring to architectures of either >>>>> types. >>>>> >>>> >>>> Yes. >>>> NOL resembles neither CEE or CES as a solution. With supporting >>>> application level session by name overlay, NOL can support some solution >>>> of style of CEE. NOL is closer to the way of CES, i.e., preventing PI >>>> prefixes of edge networks from entering into the upstream transit networks. >>>> This is done by NTR, like the ITR/ETRs in CES. However, NOL has no >>>> need to define the clear boundary between core and edge networks. And >>>> NOL is to pay more focus on the benefits for end users or content providers >>>> by facilitating the adoption of multipath routing, flexible routing path >>>> selection, >>>> ect. These incentives to wide depolyment of some solutions, in turn, >>>> benefit the impovement for Internet routing scalability. >>>> >>>>> NOL consists of two new elements and the use of the existing DNS in a >>>>> manner which returns IP addresses different from the actual address of >>>>> the host. This arrangement may cause difficulties for some >>>>> applications unless they are modified to cope with this non-standard >>>>> arrangement. >>>>> >>>> >>>> Yes. >>>> This problem is not depicted correctly or detailedly. It can be resolved by >>>> using a new namespace for NOL. The names used for NOL is formatted like >>>> email addresses, such as "d...@domain.net". The "domain.net" and IP address >>>> of corresponding NTR will be registered in DNS. NOL layer understand the >>>> meaning of the name "d...@domain.net" , and it will send a query to DNS >>>> only >>>> for "domain.net". And then, DNS will return IP addresses of the >>>> corresponding >>>> NTRs. For the legacy applications, they will still use the traditional FQDN >>>> name >>>> and DNS will return the actual IP address of the host. However, if the host >>>> is >>>> behind a NTR, the legacy applications may be unable to access the host. >>>> >>>> >>>>> The first type of element is the Name Transfer Relay (NTR), NTRs are >>>>> router-like devices, or extra functionality in existing routers, which >>>>> operate at the CE or PE location. NTRs perform a NAT-like function, and >>>>> also operate as a query server by which a NOL-compatible application can >>>>> request an address and port on which to send packets which will be >>>>> translated and sent to a host in the end-user network (EUN). EUNs use >>>>> PI global unicast addresses, but the routes covering these addresses are >>>>> only propagated as far as the NTR. The NTR is said to "block" these >>>>> prefixes from being known any further. Specifically, these EUN PI >>>>> prefixes are not advertised individually in the DFZ - nor are they >>>>> covered by a shorter prefix in the DFZ. >>>>> >>>>> Hosts in the NOL-using EUNs need not run NOL-compatible applications - >>>>> unless these applications are required to initiate communications with >>>>> other hosts in other NOL-using EUNs. Hosts inside the NOL-using EUN are >>>>> only accessible to a host outside this EUN initiating communications if >>>>> the initiating application is NOL-updated. >>>>> >>>>> NOL requires no changes to the IP stack, including the TCP and UDP >>>>> layers. An NOL-upgraded application is one which has been rewritten to >>>>> include functions of an NOL library - and this enables the application >>>>> to communicate using the host stack's conventional TCP, UDP and IP >>>>> functionality to hosts in NOL-using EUNs, behind NTRs. >>>>> >>>>> From the point of view of an NOL-application outside the NOL-adopting >>>>> EUN, if the NOL-adopting EUN has two or more NTRs, each on the link to a >>>>> different ISP, then all the hosts in the NOL-adopting EUN can be >>>>> multihomed for all communication sessions initiated by the external >>>>> NOL-application. The NOL documentation does no appear to show two >>>>> NOL-applications on different hosts in different NOL-adopting EUNs >>>>> communicating, or multihoming - but this is presumably possible by the >>>>> NTR of the host which initiates the session translating outgoing and >>>>> returning packets by which this NOL-application requests an address and >>>>> port on the NTR of the destination network. >>>>> >>>>> The most significant reason why NOL or any similar approach can't be >>>>> considered as the best solution to the routing scaling problem is that >>>>> unmodified applications running on hosts outside the NOL-adopting EUN >>>>> cannot initiate sessions with hosts inside the EUN, irrespective of >>>>> whether the applications which are intended to respond to the request >>>>> are upgraded to NOL or not. >>>> >>>> >>>>> >>>>> There is a workaround of the NTR assigning an address from a PA prefix >>>>> to each server inside a NOL-adopting EUN, so it can be reached from >>>>> outside by conventional hosts via stateless address translation. >>>>> However, this cannot provide multihoming. >>>>> >>>>> If this problem - and whatever problems arise from the DNS returning IP >>>>> addresses different from those of the hosts themselves - could be >>>>> ignored, there would still be significant scaling problems with the two >>>>> methods NTRs can use for their NAT-like translation of packets in >>>>> sessions initiated by NOL-upgraded applications. >>>>> >>>>> One approach is to use a relatively small number of IP addresses on the >>>>> outside of the NTR, with various TCP and UDP port numbers, to NAT >>>>> sessions to a larger number of hosts behind the NTR in the NOL-adopting >>>>> network. Since each port on each outside-facing address can only be >>>>> used for a single session, with a single internal host and port number >>>>> using the same TCP, UDP (or perhaps SCTP?) session, there are scaling >>>>> problems with the limitations of the number of ports and the state the >>>>> NTR must maintain. These constraints and the general volume of traffic, >>>>> may mandate the use of multiple NTRs, each handling a subset of the >>>>> hosts and having a subset of the available outside facing IP addresses. >>>>> >>>> >>>> Yes. >>>> The stateless address translation or stateful address and port translation >>>> maybe >>>> cause a scaling problems for the limitiations of the number of table >>>> entries >>>> NTR >>>> must maintain. And the legacy applications can not initiate sessions with >>>> hosts >>>> inside the NOL-adopting EUN. However, these problems may not be the big >>>> barrier for the deployment of NOL or other similar approaches. Many >>>> NAT-like >>>> boxes and proxy and firewall devices are widely used at the Ingress/Egress >>>> points >>>> of Enterprise networks, campus networks or other stub EUNs.The hosts >>>> running >>>> as >>>> servers can be deployed outside NTRs or be assigned PA addresses in a >>>> NTR-adopting >>>> EUN. >>>> >>>> >>>>> This approach has the advantage of conserving the total usage of address >>>>> space, probably resulting in a total usage of somewhat more global >>>>> unicast address space than the space actually used by the EUN behind the >>>>> NTR. >>>>> >>>>> The other approach is stateless address translation in both directions. >>>>> This is conceptually and computationally easier, but it unsuitable for >>>>> large-scale use with IPv4, since a multihomed /24 EUN would require each >>>>> of its two or more NTRs to use a /24 of PA space from each NTR's ISP. >>>>> Consequently, to multihome an EUN with 256 IPv4 addresses would require >>>>> a total of 768 IPv4 addresses. >>>>> >>>>> While it is possible to imagine new protocols between two NOL-updated >>>>> applications, an external NOL proxy so ordinary applications can >>>>> initiate communications with applications on hosts in NOL-adopting >>>>> networks, and perhaps some application of NOL to Mobility, all these >>>>> potential benefits - and the multihoming which NOL can in principle >>>>> provide - only apply for communications initiated in either direction >>>>> between hosts in different NOL-adopting EUNs when both hosts are using >>>>> NOL-upgraded applications. Therefore the same non-linear benefits to >>>>> adoption relationships found in all CEE architectures also apply to NOL. >>>>> Firstly, adopters only derive substantial benefits (portability, >>>>> multihoming and inbound TE for all their communications) after all, or >>>>> nearly all other hosts and their applications are upgraded to use NOL. >>>>> Secondly, routing scaling benefits only occur to a significant degree >>>>> when this occurs - near 100% adoption for all hosts on the Net - because >>>>> until this ubiquitous level of adoption is achieved, EUNs with PI space >>>>> need to retain it to support their portability, multihoming etc. with >>>>> conventional applications running on hosts all over the world. >>>>> >>>>> These problems, in addition to the fundamental problems of NAT - >>>>> problems with referrals, breaking of the end-to-end principle and NAT >>>>> traversal in general - mean that Name Overlay and any design operating >>>>> according to similar principles cannot be considered as the best >>>>> solution to the routing scaling problem, since several CEE and CES >>>>> architectures promise to provide portability, multihoming and inbound TE >>>>> with fewer constraints. >>>>> >>>>> >>>> >>>> NOL is designed to try to provide end users or networks a service that >>>> faciliates >>>> the adoption of multihoming, multipath routing and traffic engineering by >>>> the >>>> indirect >>>> routing through NTRs, and, in the mean time, doesn't accelarate, or >>>> decrease, >>>> the >>>> growth of global routing table size. >>>> _______________________________________________ >>>> 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
