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
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
