[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