5 ms·

See RFC 970, "On Packet Switches With Infinite Storage" by John Nagle: https://datatracker.ietf.org/doc/html/rfc970 https://datatracker.ietf.org/doc/html/rfc970

See RFC 970, "On Packet Switches With Infinite Storage" by John Nagle: https://datatracker.ietf.org/doc/html/rfc970 https://datatracker.ietf.org/doc/html/rfc970 Back then (I was studying networking as an undergrad at the time, and interned with the Arpanet team) people really did think of network congestion as a buffer allocation problem, so the obvious solution was more buffering - i.e. adding queues. Nagel was one of the first people to point out the problem with this.

kccqzy 3y ago
That's because it is obvious and intuitive even though it's wrong. In the first year of my undergrad in an assignment I added unlimited buffering to every single place that needed buffering. I remember a sense of superiority from all the extra code I wrote to do it. Of course buffering felt correct! That was long before I heard of the word backpressure.
citrin_ru 3y ago
Sometimes it is - TCP incast [1] in a fast LAN can be mostly alleviated by using switches with large buffers. Generally the higher throughput the bigger buffers you need unless having low latency is more important than low packet loss. The queue size is a tradeoff (as almost everything). [1] https://www.usenix.org/system/files/login/articles/chen12-06.pdf https://www.usenix.org/system/files/login/articles/chen12-06...
- jiggawatts 3y ago
  One of our customers bought a special switch with huge buffers, on the order of hundreds of megabytes per port. It was a specialised SKU used only for dedicated backup networks. As in, networks that process only the traffic for disaster recovery backups. Latency on that type of network traffic is totally irrelevant, and the only thing that matters is achieving the maximum possible throughput — whatever the wire protocol allows. That’s the one time I’ve seen exactly 10 Gbps sustained.
foofie 3y ago
> (...) people really did think of network congestion as a buffer allocation problem, so the obvious solution was more buffering - i.e. adding queues. I don't think people believed network congestion was a buffer allocation problem. I think people believed buffering was a way to mitigate congestion caused by a spike in traffic before allowing connection problems to surface (dropped packets, dropped connections, etc). Buffers are bounded which, by definition, means they can be filled up. Once they are filled up then the same problems that were caused by a congested network without buffering would also be experienced in connections with buffering. It's hard to believe that back then no one noticed that buffers would only take so much data. > Nagel was one of the first people to point out the problem with this. Correct me if I'm wrong, but the problem that was pointed out was instead modes of failure that take place when networks are congested but buffers are still able to take more data. We're talking about failure modes that happen when the network is congested and buffers are not completely filled but they neither can flush their data nor drop packets/connections, thus it's a steady state characterized by a network that in theory is working, but induces high latency. Also, limiting buffers is also not a fix for network congestion problems. It's a way to allow a failure mode (dropped packets) to happen much earlier than another failure mode (long queues with high latency).
- Animats 3y ago
  > I don't think people believed network congestion was a buffer allocation problem. Actually, they did, because everything in the early days had very small memory sizes. This was the 16-bit era.
  - foofie 3y ago
    > Actually, they did, because everything in the early days had very small memory sizes. This was the 16-bit era. I don't think that's a possibility. If buffers are smaller then buffer capacity was not infinite, and the same failure modes applied. Triggering dropped packets/connections was just a matter of sending enough network traffic down a pipe, which given buffers were small then it wasn't a technical feat.
Animats 3y ago
That was a long time ago. Yet we still have bufferbloat problems. Sigh.
aidenn0 3y ago
Ugh. WiFi signals aren't the best in my A/V cabinet, so I ran G.hn powerline to it. This works great 98% of the time, but occasionally there will be something that blocks traffic for a short period of time, and those things must have huge buffers. If I'm e.g. watching Netflix when there is a hiccup, I see ping times of over a minute! I wrote a program that monitors ping times and reboots the G.hn adapters when they get too high and the problem mostly went away. I tried a couple different brands of adapters, but they are all obviously the same firmware.
- withinboredom 3y ago
  Do you live near an airport (<20/50 miles/km) or near weather stations: https://en.wikipedia.org/wiki/Dynamic_frequency_selection https://en.wikipedia.org/wiki/Dynamic_frequency_selection? You are probably using channels that interfere with radar and when a router detects the radar, it should shutdown for a minute or so.
  - aidenn0 3y ago
    Does that apply to G.hn? I thought it was only WiFi on the 5Ghz band?
    - withinboredom 3y ago
      Ah, I read it as though you switched to G.hn because of wifi issues and thought you were describing that issue.

kccqzy 3y ago

That's because it is obvious and intuitive even though it's wrong. In the first year of my undergrad in an assignment I added unlimited buffering to every single place that needed buffering. I remember a sense of superiority from all the extra code I wrote to do it. Of course buffering felt correct! That was long before I heard of the word backpressure.

citrin_ru 3y ago

Sometimes it is - TCP incast [1] in a fast LAN can be mostly alleviated by using switches with large buffers. Generally the higher throughput the bigger buffers you need unless having low latency is more important than low packet loss. The queue size is a tradeoff (as almost everything). [1] https://www.usenix.org/system/files/login/articles/chen12-06.pdf https://www.usenix.org/system/files/login/articles/chen12-06...

jiggawatts 3y ago
One of our customers bought a special switch with huge buffers, on the order of hundreds of megabytes per port. It was a specialised SKU used only for dedicated backup networks. As in, networks that process only the traffic for disaster recovery backups. Latency on that type of network traffic is totally irrelevant, and the only thing that matters is achieving the maximum possible throughput — whatever the wire protocol allows. That’s the one time I’ve seen exactly 10 Gbps sustained.

foofie 3y ago

> (...) people really did think of network congestion as a buffer allocation problem, so the obvious solution was more buffering - i.e. adding queues. I don't think people believed network congestion was a buffer allocation problem. I think people believed buffering was a way to mitigate congestion caused by a spike in traffic before allowing connection problems to surface (dropped packets, dropped connections, etc). Buffers are bounded which, by definition, means they can be filled up. Once they are filled up then the same problems that were caused by a congested network without buffering would also be experienced in connections with buffering. It's hard to believe that back then no one noticed that buffers would only take so much data. > Nagel was one of the first people to point out the problem with this. Correct me if I'm wrong, but the problem that was pointed out was instead modes of failure that take place when networks are congested but buffers are still able to take more data. We're talking about failure modes that happen when the network is congested and buffers are not completely filled but they neither can flush their data nor drop packets/connections, thus it's a steady state characterized by a network that in theory is working, but induces high latency. Also, limiting buffers is also not a fix for network congestion problems. It's a way to allow a failure mode (dropped packets) to happen much earlier than another failure mode (long queues with high latency).

Animats 3y ago
> I don't think people believed network congestion was a buffer allocation problem. Actually, they did, because everything in the early days had very small memory sizes. This was the 16-bit era.
- foofie 3y ago
  > Actually, they did, because everything in the early days had very small memory sizes. This was the 16-bit era. I don't think that's a possibility. If buffers are smaller then buffer capacity was not infinite, and the same failure modes applied. Triggering dropped packets/connections was just a matter of sending enough network traffic down a pipe, which given buffers were small then it wasn't a technical feat.

Animats 3y ago

That was a long time ago. Yet we still have bufferbloat problems. Sigh.

aidenn0 3y ago

Ugh. WiFi signals aren't the best in my A/V cabinet, so I ran G.hn powerline to it. This works great 98% of the time, but occasionally there will be something that blocks traffic for a short period of time, and those things must have huge buffers. If I'm e.g. watching Netflix when there is a hiccup, I see ping times of over a minute! I wrote a program that monitors ping times and reboots the G.hn adapters when they get too high and the problem mostly went away. I tried a couple different brands of adapters, but they are all obviously the same firmware.

withinboredom 3y ago
Do you live near an airport (<20/50 miles/km) or near weather stations: https://en.wikipedia.org/wiki/Dynamic_frequency_selection https://en.wikipedia.org/wiki/Dynamic_frequency_selection? You are probably using channels that interfere with radar and when a router detects the radar, it should shutdown for a minute or so.
- aidenn0 3y ago
  Does that apply to G.hn? I thought it was only WiFi on the 5Ghz band?
  - withinboredom 3y ago
    Ah, I read it as though you switched to G.hn because of wifi issues and thought you were describing that issue.