[rrg] NOL (Name Overlay) alternative critique

Robin Whittle <rw@firstpr.com.au> Thu, 18 February 2010 10:01 UTC

Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0718B3A7C6E for <rrg@core3.amsl.com>; Thu, 18 Feb 2010 02:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level:
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ7FqS9l3inH for <rrg@core3.amsl.com>; Thu, 18 Feb 2010 02:01:11 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 16BAD3A7AC4 for <rrg@irtf.org>; Thu, 18 Feb 2010 02:01:11 -0800 (PST)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id DBE13175BE1; Thu, 18 Feb 2010 21:02:50 +1100 (EST)
Message-ID: <4B7D1048.6090608@firstpr.com.au>
Date: Thu, 18 Feb 2010 21:02:48 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] NOL (Name Overlay) alternative critique
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2010 10:01:13 -0000

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.

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.

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.

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.