[ih] Failed Expectations: A Deep Dive Into the Internet’s 40 Years of Evolution (Geoff Huston)

[Karl Auerbach]

On 5/31/23 6:47 PM, John Day via Internet-history wrote:

> What Karl was referring to, wasn’t really the Session Layer.

Actually I was.

(The larger intent of my comments was, however, merely to point out how 
we have that quite human desire to want to protect the good things we 
did during our lifetimes and that may come with a tendency to discount 
the ideas of others, a kind of techno-tribalism.)

I realized that the OSI session layer, after months of staring at opaque 
documentation, turns out to be nothing more than a means for the two 
ends of a network conversation to reliably plant named markers into the 
conversation.  (Of course the way they did it was more complicated than 
a Rube Goldberg contraption.)

This is useful for network conversations that can break (perhaps due to 
changes in position, and hence IP address) and be resumed.

The named markers become a useful way for an application style that 
always begins with a "where were we the last time we spoke" handshake.  
That allows resumption from the last session-established marker (it does 
also mean that applications need to remember things that occurred after 
that last marker - that's a job for the application, not the session 
protocol.)

On the web we tend to use cookies for this.  However, a generalized 
method that could be packed - much like TLS - into a library between the 
transport API and our applications could be a useful thing.

With regard to the point about OSI names for "the application other 
end": I do think that the introduction of domain names and URL/URIs as 
levels added a very useful form of flexible indirection to our network.  
But in our modern day I sense that more flexibility is still needed.

For example, consider a somewhat persistent application - perhaps a 
complex banking transaction.  It is possible today that one or both ends 
of that network conversation will be in motion (thus changing IP 
addresses and forcing transport re-establishment) or may split or 
coalesce due to load balancing.  In these case it is useful that 
application-level state be preservable, or, rather, that if a connection 
is re-established that it be made to the instance of "the other end" 
that holds the present state of affairs.  And that could mean that our 
naming systems need to be able to identify the pieces of applications 
that result from things like load-balancing cloning of services (or 
merging of once-separate clones.)

Some years back I dashed off a quick note on this topic:

On Entity Associations In A Cloud Network

https://www.cavebear.com/archive/public/cloud-entities.pdf

     --karl--