To learn more about networking fundamentals in order to understand papers like this one check out my udemy course Fundamentals of Networking for Effective Backends Head to network.husseinnasser.com for a discount coupon

Timestamps for topics discussed in the show 0:00 Intro 3:00 The nature of networking data center 5:30 TCP Segments 7:30 There is no Request in TCP 12:00 What so unique about Data centers? 14:00 Message Throughput vs Data throughput 18:25 Congestion Control 22:38 Homa’s Congestion Control 25:00 Server Core Load Balancing 28:30 NIC offloading 30:00 Everything Wrong about TCP 37:00 Why not QUIC? 40:00 Limitation of Streaming 44:10 Load Balancing Stream Reading 47:15 Can we treat Segments as Messages? 51:00 Dispatching Messages is Easier 53:00 Connection Orientation 1:00:00 Sender Driven Congestion Control 1:03:00 In Order Packet Delivery 1:07:00 DCTCP 1:08:30 Homa is Message Based 1:11:00 Home is Connection Less 1:12:00 Receiver Driven Congestion Control 1:15:19 Out of Order Packets 1:16:20 Homa API is not Compatible with TCP 1:17:40 Will Homa come to HTTP? 1:18:45 Conclusion

The best source of information for back-end engineering and alike! THX sharing that!

Hussein, you are always updated with the latest tech and your videos are the best. Love you content.

Thanks for the content!

Hello Hussein, The author says that TCP must use a flow-consistent routing. However, TCP practically runs over IP layer. IP packets can follow any path. That's why we have an interconnected routing system, where an IP packet can follow any hops during its travel. As a simple example, tracert command may provide different results for the same destination address. So, do you think it makes sense to treat TCP as a flow-consistent protocol? In-order packet delivery is not guaranteed by routers. Out-of-order segments are just combined in order by the TCP implementation in the host OS. That's also the reason why we all talk about ACKs, sequence numbers, retransmission, etc. What do you think?

My first reaction is we already have QUIC, why yet another protocol? Why compare to TCP and not something more modern like SCTP or QUIC? The paper doesn't pass the smell test.

Think of OSI model... The layers 5 and 6 are (de facto) inappropriate conceptual abstractions... Would the layer 7 be inappropriate too? Couldn't layer 4 support by design all usecases categorized by RPIs mechanisms (sync/async, unidirectional/bidirectional, push/pull, cardinality*), message types (query/command/event/documents/streams), configurable message delivery guarantees and order, plus enveloped message metadata? There are already layer 7 protocols/frameworks supporting that kind of stuff... Why not put that in a layer 4 protocol instead which could then address better applications needs at its level?

"We don't think this general purpose protocol works for this specific use case so clearly the general purpose protocol is crap" - This is literally what I heard. They caveat "within the data center" allot but even there I can point out major exceptions. They point out working with google, who owns KZfaq, is Homa even remotely useful for any of the video processing? Would I use Homa for handling files for google drive? With the 64k limit imposed by IP, its not even good enough for sending a photo. Even for the replication between servers within a data center for redundancy I can't see this being useful. It solves one specific use case, I have an API that doesn't return very large responses and I want to boost my requests per second to the max. I'm honestly still confused as to why this can't be done with UDP, their whole argument of hot spots rings a bit hollow to me. In most OSes the OS only has to look as far as the port numbers to figure out which process to deliver the packet to, literally the same lookup can be used to figure out what thread to deliver a request to. This type of optimization is what most routers / firewalls do, a switch never looks past the layer 2 header, a router will not look past the layer 3 headers (if you have a firewall device then yes it will look at higher layers). With respect to the NIC offload they might be able to claim they never heard of QUIC but they can't say they never heard of Spectre and Meltdown which still have OS-level mitigations because the underlying issue is baked into the silicon. If a bug exists you have to try to protect against it from outside as the card is directly processing the packets coming in from the outside world. The whole DPU market might change that (kzfaq.info/get/bejne/iZ9ipcdy3K_Zfp8.html) but DPUs can also just as easily accelerate TCP. At that point you just have dedicated processors to handle the tasks of accepting and dispatching packets to the processors / threads (not all that different to pinning certain processes to specific cores, the process they are describing would be somewhere in the softirq handling on Linux systems). As for the switches / network exceeding the servers allot of that is coming from the highest density switches are avoiding doing the optical to digital translation and switching the light directly. Those places where it is still required they are only reading as far into the packet as required (its one major reason allot of the important fields are fixed, this makes the FPGAs / ASICs life very easy). As for the load balancing over multiple links its usually done via hashing to at least avoid the network device having to keep any type of state as there are quite a few applications that don't handle out-of-order packets correctly. If we restrict to within a datacenter as they do this is seldom the case, just look up ECMP (equal cost multi-path). On cisco kit its called per-packet load balancing vs per-flow and per-packet is usually much faster as once again it doesn't require the network device to have to look further into the packet to figure out which link it must use to send it.

Can you please create videos on stack and heap memory like why we need this concepts

Next vedio on ss7 practical attack please 🤣

I didn't watch all, but at first 10 minutes things get clear, and obviously TCP was and still wrong protocol for datacenters, the main reason is that within a datacenter the needed security checking is almost zero, and many other non-usful features, actions and validations that an internet/intranet out of a DC need, a DC doesn't need those