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

[Brian E Carpenter]

Karl,

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

Or multipath transport with failover.

I think that is where QUIC multipath [1] is taking us. We tried to
do something similar with SHIM6 [2] some years ago, but it didn't fly.

The idea of a session layer was not stupid.

[1] https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/
[2] https://www.rfc-editor.org/info/rfc5533

Regards
    Brian Carpenter

On 22-Jul-25 06:15, Karl Auerbach via Internet-history wrote:
> 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
>>