Subject: [rrg] Agenda request: Presentation on new host stack architecture

From: Christian Vogt <[email-masked]>
Date: Mon, 3 Nov 2008 23:17:41 +0200

Dear program committee and all,

shortly before the previous RRG meeting in Dublin, I had proposed a new
host stack architecture as one step towards solving the routing
scalability problem.  The idea was to move the existing indirection
between hostnames and IP addresses from its current position at the
application layer down to the IP layer.  Applications and transport
protocols would thus exclusively work with hostnames, and IP addresses
would be dealt with only at the IP layer.  I would like to let the group
and the program committee know that I am now working on a concept paper
describing this new stack architecture in more detail, and that I would
like to present this at the RRG meeting in Minneapolis.  I hope to have
the paper ready within a few days, as I am aware that this is a
prerequisite for RRG presentations.  Let me for the meantime point back
to the email in which I sketched the new stack architecture initially:

   http://www.ops.ietf.org/lists/rrg/2008/msg01912.html

Like other host-based solutions, the proposed new stack architecture
provides a basis for efficient multi-homing, and it simplifies
renumbering by eliminating the need to renumber hosts and applications.
Unlike other host-based solutions, the new stack architecture has
additional advantages in terms of human-friendliness, low stack
complexity, and simplified application programming:

- Human-friendliness, because the role of a host identifier is taken by
   human-readable and memorizable hostnames rather than by cryptographic
   or encoded bit strings.

- Low stack complexity, because no extra identifier/address split is
   needed, and because IP-address-specific functionality (hostname
   resolution, IP destination address selection, NAT traversal) is
   centralized at the IP layer, avoiding the need to replicate this
   functionality in applications.

- Simplified application programming, because the existing,
   IP-address-oriented socket API is replaced by a simplified API
   providing "connect-by-hostname" and "accept-by-hostname" methods.

Note that these additional advantages provide strong incentives for
operating system vendors and application programmers to adopt the new
stack architecture.  Efficient multi-homing and simplified renumbering
alone provide only weaker incentives, because they have no or very
limited benefits for host and users.

Let me re-emphasize that the proposed new stack architecture may not be
sufficient to fully solve the routing scalability problem.  It will
certainly be a big step, because new multi-homing capabilities and the
reduced renumbering costs will make it easier to use provider-allocated
addresses at the Internet edge.  But some sort of network support may
still be needed to eliminate renumbering altogether.  Moreover, the new
stack architecture could serve as a framework for core ideas from other
host-based solutions.  Take multi-path TCP as an example.  Or the
capability from (host-based) Six/One to rewrite IP addresses in the
network as a trigger for hosts to redirect traffic to a different path.

Anyway, I am writing this down now in said concept paper.  And while I'm
doing this, I'd like to queue up for a presentation slot in Minneapolis.

- Christian

_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Christian Vogt <[email-masked]>
Date: Mon, 10 Nov 2008 18:30:14 +0200

On Nov 3, 2008, Christian Vogt wrote:

> Shortly before the previous RRG meeting in Dublin, I had proposed a  
> new
> like to present this at the RRG meeting in Minneapolis. [...]

Dear program committee and RRG folks,

finally, here is a link to the concept paper on the new hostname- 
oriented
host stack architecture, which I described in earlier emails:

http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf

I am very interested in your opinion about it.

- Christian

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 14 Nov 2008 13:45:17 +0100

On Mon, Nov 10, 2008 at 06:30:14PM +0200,
 Christian Vogt <[email-masked]> wrote 
 a message of 36 lines which said:

> finally, here is a link to the concept paper on the new hostname-oriented

That's a very good idea and one which is badly needed anyway. I
strongly regret that we have to "port" applications to IPv6: a
technical detail at layer 3 should not be visible by applications at
all and they should not need to be "ported", not more that they are
"ported" to Wifi or Ethernet or ISDN.

Therefore, your proposal addresses a very important architectural
problem of the Internet. If deployed, it would allow a much easier
deployment of new techniques, whether HIP, LISP, IPv6 or anything
else.

Some points that may need to be addressed:

* a weaker form of your proposal is implemented in many programming
languages (even in C if you use libraries like neon). The program can
connect to a program on another host using just host names (for
instance, I believe Christian Huitema mentioned several times here
that there is such an API in Microsoft products). It is weaker than
your proposal since everything is implemented in userland and
therefore such connections typically do not survive a renumbering or
rewriting.

* at least for debugging purposes, it would be great to be able to
retrieve technical connection details such as the IP addresses
actually used. Should you plan to develop a concrete API, this would
have to be handled.

* Security is of course the big problem and the current proposal is a
good start, but insufficient.

* Your plan would make us more dependent on the DNS. Today, an
application may run entirely without the DNS, which would no longer be
possible with your plan. Disclaimer: I work for a domain name registry
so I find it a very good idea :-)
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: "William Herrin" <[email-masked]>
Date: Mon, 17 Nov 2008 10:30:37 -0500

> http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf

Hi Christian,

I read your paper on the flight to MN. I understand this to be like
strategy B variant B1a
(http://bill.herrin.us/network/rrgarchitectures.html) except that the
GUID is alphanumeric.

Some thoughts:

1. The connection oriented protocol is probably the easiest problem
for strategy-B systems. If push came to shove, SCTP would probably
work though I think we can do better. If you want a challenge, try to
figure out how the connectionless protocol will work. Expecting the
app developer to figure out error correction was reasonable for UDP.
Expecting the app dev to figure out complex reconnection via multiple
source and destination locators is probably a bit much. We'll need a
way to address this in the UDP-replacement itself while keeping it a
lightweight, fundamentally connectionless protocol.

We'll probably want acks built in this time so that layer-4 has a
built-in expectation of packet returns to key the locator-changes off
of. Maybe some sort of "ack now/ack later" bit so that the the
destination stack knows whether the app needs an immediate ack or can
wait a little while and receive a collection of them.

2. I suggest a different approach to legacy app support: have the new
layer 4 treat the old-API IP address as a reformatted name in the new
system. The app may think its talking to 1.2.3.4 but its really
talking to 4.3.2.1.compatibility.net. Then equipment basically keeps
the last IP address they had in the form of a name when IPv4 finally
goes away.

3. Have you considered the differences with variant B1b? If you split
GUID and SID in addition to splitting LOC, then the origin can start
anonymous and the upgrade to a named source if the connection proves
long-lived. The anonymous origin may be limited to a single LOC until
it upgrades with something like a TCP optoin, but that keeps the
protocol light-weight for the short-lived connections.

4. For layer 3 in strategy B I think we'll always want to do
source-dependent routing. In other words, all routes will have both a
source and destination prefix. In the core the source prefixes will
mostly have a zero length but as you get towards the edge the upstream
routes (like the default route) will match the ISP prefix for the
given locator. That makes sure that the multiple LOCs for each host
route out through the correct ISP. As a side benefit, LOC spoofing
gets harder: if a host originates a packet with a false source
address, it'll die at the first router which doesn't have a route for
that source.

Food for thought.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Christian Vogt <[email-masked]>
Date: Tue, 18 Nov 2008 14:59:04 -0600

Bill,

thanks a lot for the careful review and the many great comments.  My

> (http://bill.herrin.us/network/rrgarchitectures.html) except that the

Yes, variant B1a is the classification bucket where a hostname-oriented
host stack architecture falls into.  Note however that, unlike strategy
B1a, a hostname-oriented stack architecture does not require the use
of provider-allocated IP addresses at the Internet edge.  It also works
with provider-independent edge addresses, which may be directly injected
into the global routing system, or hidden from the global routing
systems by means of a protocol like LISP or Six/One Router.  Of course,
we would want to hide them for routing scalability reasons.

> for
> strategy-B systems. If push came to shove, SCTP would probably work
> though I think we can do better. If you want a challenge, try to  
> figure
> out how the connectionless protocol will work. Expecting the app
> developer to figure out error correction was reasonable for UDP.
> way
> to address this in the UDP-replacement itself while keeping it a

Right, there certainly remains work to be done on connection-less
protocols.  But some early thoughts nonetheless:  I think the solution
depends on whether or not a connection-less protocol interacts with an
application (i.e., whether or not the protocol has a socket):

- For connection-less protocols that have sockets, the procedure could
   be as described in the paper -- i.e., exchange hostnames initially,
   and omit them in subsequent packets.  This would require a separate
   socket per session, which is not necessarily the case in the
   existing host stack architecture.  It may appear that this could
   lead to extra overhead in terms of memory and processing, but a
   clever implementation may be able do without such extra overhead.

- For connection-less protocols that do not have sockets, it may be OK
   to operate without hostnames (e.g., because a protocol is used for
   IP-related debugging only), or to include the hostnames in all
   packets.  ICMP is a protocol that is mostly used for debugging,
   hence it could operate without hostnames in many cases.  Where ICMP
   produces feedback to an application, there exists a socket through
   which that feedback can be presented to the application.

> talking
> to 4.3.2.1.compatibility.net. Then equipment basically keeps the  
> last IP
> address they had in the form of a name when IPv4 finally goes away.

I think you mean the same that I am proposing in the paper.  By
"synthesizing" a hostname, I was referring to the process of creating
"4.3.2.1.compatibility.net" from 1.2.3.4.  Are we on the same page?

> long-lived. The anonymous origin may be limited to a single LOC  
> until it
> upgrades with something like a TCP optoin, but that keeps the protocol
> light-weight for the short-lived connections.

I think the concept of "anonymous" connections may prove useful to
support hosts without a DNS entry.  These hosts could still use a
"dummy" hostname, which they generate on the fly, in order to take
advantage of the hostname-oriented host stack features.

Regarding service IDs and session IDs:  The proposed host stack
architecture in fact does have the equivalent of both:  It uses the pair
of a hostname and a service name as what you call a "service ID".  And a
connection name is what you call a "session ID".  In today's host stack
architecture, both IDs are overloaded into port numbers.

FWIW, I am personally in favor of integrating the hostname and service
name into a single name, since the usefulness of a hostname without a
service names is small.  Obviously, such integration would change
neither the way "names" (be it hostnames or service names) are resolved
into IP addresses, nor the way the name-to-address binding is secured.

> given
> locator. That makes sure that the multiple LOCs for each host route  
> out
> through the correct ISP. As a side benefit, LOC spoofing gets  
> harder: if
> a host originates a packet with a false source address, it'll die at  
> the
> first router which doesn't have a route for that source.

This is a good point.  And it already holds true for the existing host
stack architecture.

Thanks again for the review and feedback, Bill.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 20 Nov 2008 22:52:17 -0600

> deployment of new techniques, whether HIP, LISP, IPv6 or anything  

Hi Stephane -

Thanks a lot for your review and feedback.  It is highly appreciated.
And I apologize for getting back to you with delay.

> that
> there is such an API in Microsoft products). It is weaker than your
> proposal since everything is implemented in userland and therefore  
> such
> connections typically do not survive a renumbering or rewriting.

That's right.  And I think the popularity of these evolved APIs is a
good indication that application developers will adopt also the new API
provided by a hostname-oriented stack architecture.

Also, you are right that the existing evolved APIs are weaker than a
hostname-oriented stack:  First, because they do not provide an Accept
 From Hostname method.  Second, because they cannot handle address  
changes
without application-layer reconnects.  A hostname-oriented stack would
provide both.

> actually
> used. Should you plan to develop a concrete API, this would have to be
> handled.

Yes, I agree that this would be useful and necessary.

> good start, but insufficient.

Are you referring to hostname registries potentially not being
trustworthy?

> so I find it a very good idea :-)

Right, a hostname-oriented stack would make DNS a first-class entity.
I believe this is feasible because it is true for many applications
already today.  Having said this, I also acknowledge that there are
mission-critical applications that must continue functioning in the
event of a DNS failure.  It may be necessary for those applications to
operate on IP addresses directly.  I envision a non-default mode that
enables this.  Note that a similar mode will be necessary to support
legacy applications.

- Christian