Subject: [RAM] Re: I-D ACTION:draft-nikander-ram-ilse-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Mar 2007 15:59:31 +0100

I'm out of time to fully review this (but it's very
interesting). A couple of very quick comments though.

> 3.3.1.  API compatibility
...
>    Unfortunately, there appears to be a number of important applications
>    that assume more.  Basically, they assume that they can hand the
>    address (either as a binary blob or encoded as an ascii string) to
>    any other host and that host will also be able to use the address in
>    the same way.  This is the so called referral problem.  Fortunately,
>    for the present discussion, this property has already been largely
>    broken by the prevalence of NATs and firewalls, and therefore is not
>    that important any more than it once was.

I have some problems with this text. It seems to imply there is
something evil about referrals. However, they are a fundamental necessity
of any multi-party application - party A must be able to tell party B
how to find party C. Since the whole beauty of the Internet is this
ability, the issue is not the requirement. From 1981 through about
1994 (RFC 1631) IP addresses worked just fine for this.

So it isn't "fortunate" that this property has been broken. It's actually
tragic that it's been *unpredictably* broken; sometimes it works and
sometimes it doesn't.

The conclusion is nothing to do with the socket API, IMHO. The conclusion
is that we *must* design a new namespace to fix this breakage. Today
everybody implementing a multiparty application has to solve this problem
again.

> 3.3.2.  Host-Router interface
> 
>    TBD: This section needs to be written.

When you write it, please cover TCP/IP and IPSec offload, RDMA
(RFC 4296/4297), and virtual IP addressing in server clusters.
Not all "host" functions are implemented in hosts.

     Brian

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 13 Mar 2007 13:35:18 +0200

> something evil about referrals.

That is unintentional; sorry for my unfortunate wording.  The only  
"evil" about referrals is that is somewhat hard to implement in  
certain id/loc separation scenarios, and requires new infrastructure  
in some others.

> However, they are a fundamental necessity of any multi-party  
> application - party A must be able to tell party B how to find  
> party C. Since the whole beauty of the Internet is this ability,  
> the issue is not the requirement. From 1981 through about 1994 (RFC  
> 1631) IP addresses worked just fine for this.

I agree.

> tragic that it's been *unpredictably* broken; sometimes it works and

I agree.

> everybody implementing a multiparty application has to solve this  

I agree other than that fixing this breakage is somewhat hard, in the  
economic sense.  Technically I don't see any big problems; there  
exists enough of research experience on both flat and hierarchical  
name resolution and id-based routing that we know, in the technical  
sense, how to provide the required feature.  The problem is how to  
provide it in an economically sustainable way.

About the following changed wording:

   There appears to be a number of important applications
   that assume more.  Basically, they assume that they can hand
   the address (either as a binary blob or encoded as an ASCII
   string) to any other host and that host will also be able to
   use the address in the same way.  This is a strict form of
   the so called referral problem.  However, this property has
   been largely broken by the prevalence of NATs and firewalls,
   and therefore is not clear of how important it is to
   preserve it over the compatibility API.

   More generally, the looser form of the referral problem,
   where a host hands over something (as opposed to a binary or
   ASCII compatible address-like string), is clearly something
   that has to be solved.  That is, designing a identifier new
   name space should allow the hosts once more refer to other
   hosts (or other objects), through using the new identifiers,
   in a persistent and location-independent way.  However,
   whether this support should be included to the legacy APIs,
   and especially to the IPv4 API where referrals between hosts
   work relatively poorly today, is an issue where one should
   carefully consider the benefits vs. the added complexity.

> Not all "host" functions are implemented in hosts.

Ok, tnx for the tip.  I added it to my internal version as a note.

--Pekka