[ih] Separation of TCP and IP

[Toerless Eckert]

On Thu, Jun 23, 2022 at 11:02:21PM -0600, Grant Taylor via Internet-history wrote:
> I think that I've read public accounts of CloudFlare and / or Netflix doing
> user space TCP/IP stacks.
> 
> Sorry, I'm not at liberty to discuss what my $EMPLOYER does.

Ah, then it's not interesting anyhow ;-)) Luckily there is also
great public work at least from Netflix, such as Randy's:

https://openconnect.netflix.com/publications/asiabsd_tls_improved.pdf

(which is in the kernel though.)

My point was that to make user space easy you would have wanted to
mux/demux in the kernel and do the rest (after demux on receipt, before
mux on sending) in per-app userland processes. We have this for UDP,
we do not have this for TCP. This may be something that's happening
in DPDK or other more modern approaches (i am not on top of all those
APIs), but we just didn't have it historically for TCP.

> > We have multiple decades of managing network traffic based on 5-tuple
> > with well-known port numbres. This has eroded in the past decade for
> > Internet traffic due to end-to-end encryption and will erode even more
> > due to QUIC.
> 
> I've long been a fan of discrete ports for things and not shoving everything
> over -- what I'll call -- bearer protocols; e.g. HTTP(S) / QUIC.
> 
> Maybe it's my preference for the esoteric, but I'm actually quite happy with
> IPsec transport mode mesh between my servers.

Then you probably where not under pressure to make more money by
being able to render an advertisement on a screen after one RTT
of packets without the network knowing about it - because 10 msec
later viewer ADD would have kicked in and the product would not 
have sold ;-)

But of course, the work done for QUIC has started to see a lot more
(IMHO) beneficial use-cases.


> > There where a few drafts pointing out the issues that are yet to come
> > with QUIC proliferation.  If we would not have had this history, but one
> > where like we will get it with QUIC now there are only meaningless UDP
> > port numbers and no other visibility, then i wouldn't even dare to
> > predict how a lot of the stuff we did with those 5 tuples would have
> > evolved over the decades.
> 
> I think we're about to enter a time when the only way to viably do anything
> is to actively monkey in the middle traffic so that we have application
> layer visibility into the data streams.

;-) That is a whole other thread

Cheers
    Toerless

> > Granted, we could probably had it half way, so i was justing about the
> > extreme case.
> 
> ACK
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history