Just as the network can only have a relatively small amount of traffic actually "in flight" but lots can be stuck in buffers - so likewise only a relatively modest amount of containers can be on ships in the ocean.
You need a buffer or every little inconsistency reverberates and it gets out of hand, but bufferbloat shows how too much buffering makes things worse not better. If your metrics say (and some trivial metrics do) that the huge buffer is better, your actual experience contradicts that as everything feels like you're wading through molasses.
I don't have any relevant expertise to judge what the right metrics are for international shipping, but it certainly raised my eyebrows that "Let's make the buffer bigger" is seen as automatically a good idea.
Of course, a network buffer is very different from a container port's stacks, maybe this genuinely is going to make a huge difference. I think more likely it turns out to make no real difference, but can be portrayed as a genius idea that just wasn't embraced wholeheartedly enough to be effective.
Mmmm. Doesn't necessarily hold as packets don't exist sans payload. You'd have to add an extra layer on top of the TCP logic to represent the logistical processes involved with moving packets to be filled with payload which are themselves not payload to places they are to be filled.
In a way, it sets off more token ring-ish bells for me for some reason.
“Bufferbloat is the undesirable latency that comes from a router or other network equipment buffering too much data. It is a huge drag on Internet performance created, ironically, by previous attempts to make it work better. The one-sentence summary is ‘Bloated buffers lead to network-crippling latency spikes.’”.
Increasing buffer sizes (increasing the number of containers stored) can have perverse effects that make the situation worse - although it is obviously unclear what the effects in this particular situation could be.
Hopefully the Flexport CEO has read the situation and consequences correctly and his suggestion helps, although chances are it won’t help much. Alternatively it could exacerbate the problem e.g. stacking more than two high could slow down retrieval enough that it ends up being net negative because truckers are deadlocked.
Destroying empty containers is one type of dropped packet. Destroying or discarding container contents (e.g. food gone off, end manufacturer gone out of business, parts sourced elsewhere) is another kind of dropped packet.
Quite a few comments here seem to imply this is some obvious silver bullet to fix the problem, when clearly the problem is far more complicated than that.
Hm, I think that analogy is too much of a stretch to yield interesting results, to be honest.
I suspect that global supply chain actors follow very different dynamics from naive TCP congestion control implementations (i.e. additive increase, multiplicative decrease), of which Bufferbloat is an emergent phenomenon.
Also, the solution to bufferbloat isn't making the buffers smaller again (there is no generic "correct" buffer size as that depends on the end-to-end RTT, but this can vary across flows at a given choke point). What works is to either make buffers or the endpoints' congestion control algorithms aware of the phenomenon.
The thing is, we're trying to solve a 90 day problem, where the packets have an 18 day round trip. And once an empty container is parked in a parking lot (without the trailer it's sitting on) you can just leave it there for years with close to zero consequences.
The downside at this point is that all the retail items for this holiday season won't be on shelves for christmas, so the damage done to brick and mortar sales industry has already been done
