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

[Vint Cerf]

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> 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
>
>      --karl--
>
>
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> 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