Acconut
commented
8 years ago The problem described as Bufferbloat is actually a rather simple one once you get the idea. Let me try to explain it: Whenever an application wants to send data across a network, the packets may not be immediately transferred but end up in a buffer since the network has a limited bandwidth. Bufferbloat now may occur if this buffer is managed poorly and the buffer's size is wrongly configured. In the most simplest scenario, you can imagine the buffer as a First-In-First-Out queue, meaning the first packets which get put in there will leave first. However, if you have an application which fills this buffer extreme quickly, for example a file upload, the packets from other application will get put at the end of the queue. In the end, the second application will experience enormous network delays, not because the bandwidth is low but because the buffer/queue is managed improperly.
This is an rather important topic because file uploads are usually background tasks. For example, you upload your latest holiday photos to the cloud while checking your emails or reading news. These foreground applications will feel unresponsive and slow because the buffers are "bloated" by the uploading task, even though loading mails takes a fraction of the available bandwidth.
LEDBAT, which the author mentioned, it a attempt at preventing this issue by providing a better way to manage these buffers/queues, very briefly explained.
If you want to learn more about this topic, I can recommend a few links: https://www.youtube.com/watch?v=XB3w09VZn7g https://www.youtube.com/watch?v=y5KPryOHwk8 https://gettys.wordpress.com/bufferbloat-faq/ https://tools.ietf.org/html/rfc6817 http://www.bittorrent.org/beps/bep_0029.html
The obvious question is, why we didn't specify a solution (which seem to exist) to this real problem? The answers is that it's not always possible. For example, if you develop a native BitTorrent client, you may have access to the kernel and all kind of specific APIs, such as direct interfacing to TCP and UDP connections. However, in other environments, e.g. the browser (which was a primary target of the tus protocol), you are way more limited in these terms because you have basically no way of shaping the network traffic in any helpful way to reduce the impact of Bufferbloat.
Regarding the issue: We are aware that there are some rather old discussion which have not been addressed since the target a problem outside of tus' scope. Furthermore, development on the protocol itself has slowest down after the 1.0 release as our focus has moved from the specification to its implementation. Right now, we are working towards the 1.1 release of the protocol which we expect to come this month.
Hola! I was researching my options for a resumable HTTP upload protocol and it seems that tus is the only one really so we will likely adopt it at Blockai. While Googling around, I came across this comment on HN:
I couldn't quite make out what it meant and was wondering if someone here could help me understand what it means and if it's something I should worry about.
Also, I'm seeing a few issues on GH from 2015 (e.g. https://github.com/tus/tus-resumable-upload-protocol/issues/76) and was wondering if the standard is still alive and well.