[ih] Separation of TCP and IP

[Toerless Eckert]

On Fri, Jun 24, 2022 at 02:20:21PM +1200, Brian E Carpenter via Internet-history wrote:
> Woof woof woof!

The two squirrels on my patio fence typically manage to shoo away the
chihuahuas typically worn by people around here as fashion accessories
easily. Alas, i wouldn't know how to transcribe those squirrels screams.
(oops.. and i didn't mean to imply you're a chihuahua ;-)

I wonder how you define app vs. non-app. And whether/how that
distinction was perceived or considered relevant back in the days.

Recent wisdom would makes me think that it would be nice to have
protocol stacks designed to let my (e.g.: linux userland) application
code do everything it can, and leave only those parts to (e.g.: linux kernel)
land that MUST run there because it multiplexec across applications.

Alas, this is not how TCP stacks where written. Instead they moved
the whole TCP protocol into the system level (linux kernel), making
per-application optimizations quite painful and slow to evolve. All
the Foo-over-UDP that has evolved is at least in part prove of that
problem.  Starting maybe with Steve Casners unwillingness?/inability?
(don't remember which one it was ;-) to hack SunOS kernel sources when
implementing RTP and renewed ever since, not QUIC to the latest.

Of course, userland accurate scheduling of packet sending/processing
was back then too expensive, so one can see why one wanted to keep
this all out of 'userland', but even in the 80th microkernel designs
started to appear to solve that problem, and nowadays it _should_
really not be a problem anymore with quite efficient multithreading
in user land.

Cheers
    Toerless

> I was just curious to see where OSI stood on this question in the
> 1980 Zimmermann paper. No trace of datagrams really, at that time,
> except as a possible future addition. But on the session layer, he
> wrote:
> 
> "Protocols for the Session Layer
> No standard exists and no proposal has been currently available,
> since in most networks, session functions were often considered as
> part of higher layer functions such as Virtual Terminal and File
> Transfer.
> A standard Session Layer Protocol can easily be extracted
> from existing higher layer protocols."
> 
> There is no suggestion that the session layer was intended
> to provide resilience and/or security, which I think is
> how we'd look at it today. In their own ways, SCTP, MPTCP,
> TLS and QUIC are all about that.
> 
> All the same, I think Zimmermann was right - what OSI conceived
> of as session layer functions have always been mainly embedded
> in apps, and the same goes for the elusive Presentation Layer.
> 
> Regards
>    Brian Carpenter
> 
> On 24-Jun-22 13:52, Dave Crocker via Internet-history wrote:
> > On 6/23/2022 6:41 PM, Jack Haverty via Internet-history wrote:
> > > and they have no need for "sessions".
> > 
> > 
> > This is a squirrel and I'm inclined to chase after it.
> > 
> > In the context you've used this clause, sure.  But I suspect we'd be in
> > better shape if we'd actually taken advantage of the construct more
> > generally.
> > 
> > I was intrigued to discover, some years back, that TLS is actually
> > specified within a session layer model, though this bit of generality
> > has apparently not been otherwise exploited.
> > 
> > The benefit of this layer is the tiresome one of indirection. The
> > current reality is that one process interacts with another through a
> > transport protocol. If this interaction is based on continuing state,
> > there is no convention for maintaining process-process context if that
> > transport interaction is lost. So the interaction has no robustness
> > against outages or mobility.
> > 
> > A session layer can fix that, hiding changes from one transport
> > 'connection' to another. Move from Wi-Fi access to cell-based access and
> > the applications see only some performance hiccups, but no loss of
> > the... session.
> > 
> > woof.
> > 
> > d/
> > 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history

-- 
---
tte at cs.fau.de