2 ms·
This looks like they learned from tcp_random_drop which was a method for combating syn flooding back in the day, and the principle appears consistent and applie
by motohagiography 5y ago
This looks like they learned from tcp_random_drop which was a method for combating syn flooding back in the day, and the principle appears consistent and applies to higher level abstractions like filesystem writes and others.
I'm interpreting that congestion may be the result of the client expectation of sending into a queue based on the maximum possible availability of a channel, whereas if you add randomness to the percieved availability of the channel across all clients, all clients will then send based on the perception/calculation of the mean availability, which is always less than the max as they all converge/revert to that mean.
(crazily, it could imply if we halved speed limits but didn't really enforce them, people would mentally reserve twice the time duration for a given trip, and therefore only choose discretionary travel based on that doubled time commitment, reducing the number of people using the roads together at a given time, while the ones on the road could travel double the percieved speed limit)
- fizwhiz 5y agoThis reminds me of https://en.wikipedia.org/wiki/Thundering_herd_problem https://en.wikipedia.org/wiki/Thundering_herd_problem
- an1sotropy 5y agoThis is history that I wish I knew in more detail, but I think TCP learned[1] it from Ethernet, and Ethernet learned[2] it from ALOHAnet[3] (in the 1970s). [1] https://cs162.org/static/readings/jacobson-congestion.pdf https://cs162.org/static/readings/jacobson-congestion.pdf [2] https://www.i-programmer.info/babbages-bag/398-ethernet.html?start=1 https://www.i-programmer.info/babbages-bag/398-ethernet.html... [3] https://www.cs.utexas.edu/users/lam/NRL/backoff.html https://www.cs.utexas.edu/users/lam/NRL/backoff.html