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

[Karl Auerbach]

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--