[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] On identifiers, was: Re: Does every host need a FQDN



On 14 aug 2008, at 1:20, Tony Li wrote:

In one sense, accepting the socket API as immutable is to ossify the entire architecture perennially when we can all clearly see that mistakes were made
(albeit with the best of intentions and all available foresight at the
time). Shouldn't we, as a research group, be looking past that to what a
new socket API might also look like?

Is this something that we as the RRG want to take on?

(We do seem to have a fair contingent of computer science professors in our midst so why not...)

We need to be realistic and recognize that fixing the API isn't going to do anything to solve the current routing scalability problem. Fixing the API is a worthwhile goal from an architectural perspective, but I'm afraid that's not reason enough to actually do the work, let alone get it deployed.

So: what would be the benefits of such a new API? As someone who has just enough experience programming with the current socket API to be utterly frustrated by it, I can see how cleaning everything up and bringing it into the 21st century would be useful, but probably still not enough to justify the work. (Re mundane but annoying stuff like expressing disambiguated IPv6 link locals in applications.)

I think the answer lies in the areas of cryptographic identifiers and multiaddressing and multipath. The SCTP people were forced to create their own API because SCTP does all kinds of stuff that TCP doesn't do. I'm not familiar enough with HIP to know how they handle this, but I'm guessing HIP has some API hooks as well. If we can unify all of this stuff in such a way that applications can work over things like SCTP and HIP without actually needing to understand those protocols, and not just in some compatibility mode, and, very important, be able to do referrals without loss of information, that would be a compelling reason to do this work. (Note though that fixing referrals probably means updating dozens of RFCs that do referrals by IP address.)

Then at some later point we can drop in loc/id stuff without needing to revisit applications.

Before the flames start, please consider the ability of a host to support both a new and old version API simultaneously, with the older API being
deprecated.

Oh, I thought you wanted to remove the existing socket API to give people an incentive to adopt the new one...

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg