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

[Karl Auerbach]

Why do I (and also ISO/OSI) believe that an association protocol 
(between application layer and transport layer) ought to be there?  And 
why couldn't DNS take up the slack?

(This may not be strictly a "history" point.  But when we talk about 
Internet history it can be as interesting to note the roads not taken as 
to deal with those roads that were taken.  I wish modern RFCs were more 
willing to discuss rejected alternatives.)

Consider an IPv4/6 connection between an application on a mobile device 
(whether that be a phone, a vehicle, etc).  Suppose that application is 
doing something that takes time - such as you are watching a video or 
you are engaged in a game.

As you move you may be acquiring and losing IPv4/6 connectivity and 
addresses as you move from provider to provider.  That means that you 
can't sustain a single, continuous TCP connection; rather you need to 
re-form that transport but maintain the association with the remote 
service.  (This can get more "fun" if that service is itself in motion 
across the net or, for cloud services, the service itself may have a 
dynamic set of instances.)

When I was working on mobile computing we had to deal with connectivity 
changes that were rapid - our worst case at the time was John Roberts on 
his bicycle riding across the Sun campus - transitions every few 
seconds. (We were operating below the level of TCP.)  In the world of 
vehicle-to-* communications, transitions and connectivity persistence 
can be at the sub-second level. (Not all of those transitions would 
result in IP address changes.)

Just walking down the street with a mobile phone can result in that 
phone dancing to IP connectivity changes as the phone binds to different 
wi-fi access points or 4/5G providers.  (I am sure we have all 
experienced the delay when a mobile application has not yet realized 
that it has lost access via a provider and needs to switch.)

DNS can not handle the dynamics of such a situation; DNS greatly depends 
on caching in order to scale.  In our modern world, the load of doing 
updates and cache-updates to deal with mobility could be immense.

We've seen how mobile-IP deals with things: a kind of juggling act with 
multiple IP addresses and a kind of triangular packet routing.  It is 
not elegant (and I'm not sure how much it is used in practice.)

In the world-wide-web context (HTTP/HTTPS) we've got a state identifier 
that is useful for transport-spanning associations - cookies.

It would be useful if there were a more generalized mechanism so that 
one could establish something like a TCP transport connection but which 
spanned the lives of more than one underlying TCP transport connection.

The ISO/OSI approach was scary to read and was vastly over-designed.  
The thought of implementing it was fearful and engendered nightmares of 
protocol stacks that had to remember higher level data.  But basically 
all it amounted to was a simple protocol to established named 
checkpoints as a network association progressed.  Capture, storage, and 
replay of higher level data was not part of the protocol, although that 
was not clear from the specification.  The end points would be 
responsible to hold (and be able to re-play) material after the latest 
named checkpoint (the protocol machinery would not do any of that 
holding/replay, that's up to the end points.)  Thus, each re-connection 
of a new underlying transport connection would begin with a conversation 
that was essentially "where were we, what was our last named 
checkpoint?"  If the two ends agreed on that named checkpoint then the 
ends would roll-back and re-play since that checkpoint.  (This kind of 
incremental commitment is not uncommon in the world of databases.)

Much of this can be done in end-point libraries (as we often do with 
TLS) rather than being built deeply into an in-kernel protocol stack.  
Applications would have to understand that data since the last 
established checkpoint is data that could be delivered again. (Or a 
session protocol API could have a mode to help with that.)  Again, this 
kind of thing is fairly common in databases.  This would, of course, 
require changes to how applications use the network - rather than a 
transport byte stream they would be operating on streams that are 
punctuated by named checkpoints, re-synchronize events, and obligations 
to replay and re-receive upon those re-sync events.

(I might add that this kind of thing could deal with the fact that TCP 
is a stream without clear delineation of higher level "messages".  There 
is a lot of code that assumes that the data arriving out of a tcp.recv() 
function will always be the exact same sequence of bytes that were in a 
tcp.send() performed by the sender.  Remember the Nagle algorithm?)

         --karl--

On 7/21/25 7:08 AM, Andrew Sullivan via Internet-history wrote:
> Hi,
>
> On Sun, Jul 20, 2025 at 03:24:58PM -0500, Karl Auerbach via 
> Internet-history wrote:
>>
>> The second is a note about the question of "what are we naming?" This 
>> is particularly an issue in modern applications in which the network 
>> partner of a client may move, split, or merge during a client-service 
>> interaction (and thus take on different IP addresses and port numbers 
>> [and different transport connections] as that interaction progresses 
>> over time.)  (This is why I am so fond of the idea of an association 
>> protocol layer between applications and our transport layers.)  The 
>> ISO/OSI folks may have wrestled with this via things like 
>> "application entity titles", but they didn't do a very good job of 
>> expressing the problem they were trying to solve or their solutions.
>
> I have never understood why there is _supposed_ to be a problem 
> there.  DNS names are an indirection layer, and if we doubt this we 
> have CNAME and DNAME to correct our misundderstanding.  The True Name 
> of a thing is, to my mind, way too mystical for something like 
> services on a network.
>
> So, to bring this remark back to something to do with history, _why_ 
> did this perceived need arise?
>
> Best regards,
>
> A
>