So let's say we put a packet on the sushi belt, and it trundles along, and then it gets to the other end, and the other end takes it, and puts its own acknowledgment packet on the belt headed back to us. If we won't see that reply, we know to resend. O.k. great.
-
-
Generally packets enter and leave these buffers in order, but in some networks you can have priority lanes here, giving priority to some packets over others. At AWS, our belts move so quickly and there are so many free slots that we don't need to do this, it'd be pointless.
Show this thread -
But if there is congestion, and slots are busy, it's because senders are sending too much; it's key that they know quickly, so we make these buffers small. The problem of having these buffers too big is called buffer bloat (https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/ …)
Show this thread -
This can all be very confusing without the right mental model. Because we generally want one kind of buffer - the window size - to be big, but another kind of buffer - the buffers between links - to be small.
Show this thread -
But if you see the network as train-cars or sushi on a belt, what you can see is that what we *really* want is to fill as many slots as we can when we're sending data! That's really all that's going on.
Show this thread -
One problem with the metaphor: packets don't actually go in loops, they come at the other end, so unlike a sushi belt, there's a kind of off-ramp at each end. Also packets only enter and exit at the ends. There's really no perfect metaphor.
Show this thread -
I'm going to meditate on better metaphors, so that's it for now :)
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.