The Daily PPILL
Published in

The Daily PPILL

Shipping Containers, work, and TCP/UDP? — The Daily PPILL # 128

Shipping Containers, work, and TCP/UDP? — The Daily PPILL # 128

Some time ago, I was listening to a Fresh Air episode about the global supply chain and while hearing about the extreme complexity of properly orchestrating trans-shipment and to efficiently store each container, it came to mind how this could be used to explain two of the fundamental transport protocols that make the Internet work. If you are in this business, you know what I am talking about, but even if you’re not, you have probably heard about them.

The first one, TCP, makes a lot of sense for one of the first important applications of the Internet: file transfer.

Everything that travels through the Internet, is obviously digitized, but then is also separated into smaller pieces, called packets. These are transmitted, one at a time (and sometimes in parallel), to the destination. This means that packets have to be reassembled once they are received. But packets sometimes get “lost”, either because they are never received, or because there are errors in them. TCP “knows”, and because of that, packets are re-transmitted and the file is reassembled completely. You may imagine that in a noisy network, it can take quite some time to put everything together in the correct order, because of constant retransmission.

This is similar to what happens at ports, where multi-container shipments have to be transferred from one vessel to another, even when they are not necessarily loaded close to one another and in order on either ship.

UDP is different. UDP doesn’t care that much about lost packets. If they are lost, they are lost. But there is one thing that UDP cares much for: timing. That’s why UDP is used for your Zoom calls, and well, anything that includes streaming. When packets are lost, well, they are lost, and voice comes through garbled, but still somewhat in time.

Going back to our container analogy, for shipments that are not being transshipped, the objective is to offload everything as fast as possible. No matter in which order.

The analogies abound, but one big difference is in where the “routing” intelligence resides. At the port, there are complicated arrangements of shipping manifests that I don’t fully understand. On the network, each packet “knows where it is going”.

Will there be a future where shipping containers will enroute themselves to the proper vessel or warehouse and where we could apply these techniques to physical containers? To some extent, the future is here. There are airports, and logistics distribution centers that are already doing some version of this. But imagine leveraging everything that we have learned about TCP/IP networks, the way errors are handled, the metadata, taps, BGP to re-route if something fails (like a crane).

Perhaps we could also use it ourselves, and identify when to operate in one way or another. There are times when “crossing all our t’s and dotting our i’s” is important, others, when time is of the essence. How are you feeling today? More UDP than TCP? Or the other way around?

As published on The ChannelMeister

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
The ChannelMeister - Huba Rostonics

The ChannelMeister - Huba Rostonics

Uncovering insight. Tracing the path forward. Marketing and Channel Ecosystems Strategist, helping companies navigate change and grow.