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

[Christian Vogt]

Bill,

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

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

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.

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

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.

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

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?

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

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.

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

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