[ih] History of Naming on The Internet - is it still relevant?

[John Day]

I apologize for bring up this topic after it has been quiet for a couple of weeks. It sparked my interest, but it was the end of the summer session and I got swamped with all of that.

Why do several of you (apparently all) find the Sockets API so good? This was really surprising.

For me, it is one of the 2 or 3 Internet standards (is it really? or just what everyone uses?) that has done the most damage to the Internet architecture.

It exposes far too much to the application. It has very little of the usual properties of an API to create a black box. It requires the application to modified to use the Net.  It seems counter to the Unix philosophy to make everything look like a file operation.  In fact, when the first Unix was put on the Net in 1975, that was the API, something like, <file-desc> = OPEN(USCD/Telnet).
The file-desc would be a form of port-id and could be easily extended for other connection specific parameters. There was a meeting at some point to discuss what to put into Berkeley Unix but Joy was too taken with Sockets to adopt a more Unix-consistent API.
I have been told that the Microsoft transition to IPv6 was delayed two years because every program that used the Net had to be modified.
A file-oriented API would have allowed a seamless transition to Application-names and getting rid of the well-known port kludge. No one would have noticed.

Hope I haven’t stirred things up too badly.

Take care,
John Day

> On Jul 23, 2025, at 23:31, Karl Auerbach via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> On 7/23/25 6:28 PM, Craig Partridge via Internet-history wrote:
>> On Wed, Jul 23, 2025 at 6:55 PM touch--- via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>> 
>>> The user thinks in terms of socket connections; the rest can be opaque.
>>> 
>> I'd argue that the history of the Internet says that's not quite true.
>> Users care about the path their traffic takes in the network (various
>> issues about ensuring certain traffic did not transit certain countries
>> over the years).   Users care about performance, and before carriers sorta
>> figured out how to ensure good service, we found users playing around with
>> reaching into the routing layer.
> 
> The socket abstraction has a meritorious aspect: it is simple.
> 
> But users need ways to express the kind of service that a socket should provide.  And, indeed, there are some simple mechanisms for that.
> 
> But once one digs into the idea of expressing "what kind of service does this connection need" things can get complicated really fast.
> 
> Fred Baker and I worked on the RSVP protocol.  (I did a fairly extensive client implementation, Fred the the in-router hooks.) It was hard.  There are so many dimensions of "service" ranging from a simple "bit/second rate" (over what time span?) to some sort of expression of dynamics (burst behavior of the flow).  But even with a reasonably extensive means to express connection service RSVP was largely stuck with a relatively limited ability to affect actual routing path setup (and re-setup).  And RSVP did nothing to help a client chose among multiple equivalent service peers (equivalent except for the network path to reach them.)
> 
> Steve Casner and I were doing network video with potentially many separate streams of video and audio from many sources to many destinations.  Lip sync was a huge problem.  Beyond the fact that clocks on senders and receivers drift with respect to one another, often our code was faced with the question "do we pause the stream or do we insert a fig-leaf to cover the missing data?"  If the fig leaf got large or frequent that coverage could involve switching to an alternative (but equivalent, except for the network path) data source.
> 
> Our code was on top of UDP, which somewhat simplified things. But even then we never found a good solution except to ask the providers administratively to provision more resources.
> 
> But sometimes the problem was not the data path itself but rather, the client's choice of which (equivalent) server to select (which would imply a choice among data paths.)
> 
> I took the effort further and asked whether we could figure out a way to let a client discover an alternative content source, or select among multiple potential sources, within a reasonably short period of time (not much more than a single round trip time) and without seriously burdening the routing fabric or the routers themselves?
> 
> The method I came up with (circa year 2000) was inspired by Van Jacobson's multicast traceroute (mtrace).  I never had a chance to implement it in Cisco IOS (I was going to use the on-again/off-again Java VM engine that was in some IOS experimental versions.)
> 
> I used a combination of a hypothetical IP header and an Integrated Services T-Spec (RFC 2215) as a means to express the proposed service level.
> 
> There is a very rough, incomplete draft of the idea up on my website.  (It was never sufficiently developed even to reach the level of an Internet Draft.)
> 
> Fast Path Characterization Protocol (FPCP)
> 
> https://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html
> 
>     --karl--
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history