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

[Brian E Carpenter]

Personally I liked "name-based sockets", but it's still not quite
what Karl was getting at:

https://datatracker.ietf.org/doc/html/draft-ubillos-name-based-sockets

Regards
    Brian

On 02-Jun-23 08:31, Vint Cerf wrote:
> QUIC has some simplified elements of "shared markers" for rapid recovery of a broken connection up to and including change on one side's IP address
> 
> v
> 
> 
> On Thu, Jun 1, 2023 at 4:25 PM Karl Auerbach via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
> 
>     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 <https://www.cavebear.com/archive/public/cloud-entities.pdf>
> 
>           --karl--
> 
> 
> 
>     -- 
>     Internet-history mailing list
>     Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>     https://elists.isoc.org/mailman/listinfo/internet-history <https://elists.isoc.org/mailman/listinfo/internet-history>
> 
> 
> 
> -- 
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
> 
> 
> until further notice
> 
> 
>