4 ms·

I got called a paranoid a couple of years ago, because I said that my provider slows down long downloads, since every download starts fast, but after a few mega

by guappa 3y ago

I got called a paranoid a couple of years ago, because I said that my provider slows down long downloads, since every download starts fast, but after a few megabytes they become slower and slower.

lxgr 3y ago
Are you using cable by any chance? This is a pretty standard feature of DOCSIS, I believe. It allows bursting above the provisioned connection speed for a few seconds when there's capacity on the shared network segment.
callalex 3y ago
That’s not paranoia, it’s bog standard traffic shaping that ISPs have been doing since the 90’s or even earlier.
- guappa 3y ago
  Eh, others in the discussion claimed it would be completely impossible for an ISP to do this thing, due to how network protocols work. Anyway, annoying… at least http supports resuming, so it is possible to kill and restart manually, or use aria2c to circumvent it.
  - kaetemi 3y ago
    ISP controlled modem counts your incoming data in a short rolling window. If it exceeds a value, it throttles below your normal speed and buffers or drops incoming packets to slow things down, until the bandwidth budget is compensated for (and the dropped packets are all counted, so it could be stuck there longer than anticipated), then switches to normal speed until traffic goes below a threshold, then switches back to full speed burst. Worst case the flow control reacts slower than the modem burst switching and you end up in an oscillating pattern. The trick is just to do your own rate limiting without burst at the right limit, that bypasses whatever shitty burst implementation your ISP modem has and weird shit won't happen anymore.
kaetemi 3y ago
If you set your router to limit bandwidth below that initial burst speed, to your actual connection speed, you'll get consistent fast speed. The burst mechanism of your provider possibly squeezes below your normal speed to compensate for the burst, but ends up confusing TCP flow. Those burst and squeeze cycles can cause some undesirable bandwidth oscillations.
- lxgr 3y ago
  Any TCP congestion control algorithm worth its salt should be able to adapt to varying path capacity these days, especially given how common traffic shaping with bursting is in residential connections.
  - kaetemi 3y ago
    You can safely assume the bursting itself is badly implemented on shitty ISP modems and causes spikes of high packet loss and latency when it switches. Say you're bursting 1gbps on a connection with 100ms latency. That connection squeezes to 20mbps suddenly. In the best case in those 100ms that the sender cannot even react to the change, we receive 10mbytes. Those 10mbytes that now have to be throttled away either get dropped or end up in a buffer. Now you either have a 5 second backlog latency or massive packet loss for 100ms while this resolves. And things overcompensate. And worst case, you end up in a oscillation pattern, the throttle goes off, and you burst again. This happens and is measurable.

by guappa 3y ago

I got called a paranoid a couple of years ago, because I said that my provider slows down long downloads, since every download starts fast, but after a few megabytes they become slower and slower.

lxgr 3y ago

Are you using cable by any chance? This is a pretty standard feature of DOCSIS, I believe. It allows bursting above the provisioned connection speed for a few seconds when there's capacity on the shared network segment.

callalex 3y ago

That’s not paranoia, it’s bog standard traffic shaping that ISPs have been doing since the 90’s or even earlier.

guappa 3y ago
Eh, others in the discussion claimed it would be completely impossible for an ISP to do this thing, due to how network protocols work. Anyway, annoying… at least http supports resuming, so it is possible to kill and restart manually, or use aria2c to circumvent it.
- kaetemi 3y ago
  ISP controlled modem counts your incoming data in a short rolling window. If it exceeds a value, it throttles below your normal speed and buffers or drops incoming packets to slow things down, until the bandwidth budget is compensated for (and the dropped packets are all counted, so it could be stuck there longer than anticipated), then switches to normal speed until traffic goes below a threshold, then switches back to full speed burst. Worst case the flow control reacts slower than the modem burst switching and you end up in an oscillating pattern. The trick is just to do your own rate limiting without burst at the right limit, that bypasses whatever shitty burst implementation your ISP modem has and weird shit won't happen anymore.

kaetemi 3y ago

If you set your router to limit bandwidth below that initial burst speed, to your actual connection speed, you'll get consistent fast speed. The burst mechanism of your provider possibly squeezes below your normal speed to compensate for the burst, but ends up confusing TCP flow. Those burst and squeeze cycles can cause some undesirable bandwidth oscillations.

lxgr 3y ago
Any TCP congestion control algorithm worth its salt should be able to adapt to varying path capacity these days, especially given how common traffic shaping with bursting is in residential connections.
- kaetemi 3y ago
  You can safely assume the bursting itself is badly implemented on shitty ISP modems and causes spikes of high packet loss and latency when it switches. Say you're bursting 1gbps on a connection with 100ms latency. That connection squeezes to 20mbps suddenly. In the best case in those 100ms that the sender cannot even react to the change, we receive 10mbytes. Those 10mbytes that now have to be throttled away either get dropped or end up in a buffer. Now you either have a 5 second backlog latency or massive packet loss for 100ms while this resolves. And things overcompensate. And worst case, you end up in a oscillation pattern, the throttle goes off, and you burst again. This happens and is measurable.