may you go over why it is bad to have (almost) no buffer at all? what is wrong with high packet loss when there is not enough bandwidth? is it just that TCP fails badly in those situations? thanks!
Mon, 10 Dec 2012 20:05:15 UTC
The idea to have to have tools to actually control the internet data stream is compelling. It would be sweet to actually have a user friendly program that not only would measure latencies of the internet,but would recomend the best way to deal with these delays by monitoring all of major components of the system(including cpu,gpu,memory,OS and bandwidth).The program then could remotely(automatically) tweak the connection to give you the best throughput based on the datastream .
Sat, 10 Nov 2012 10:22:57 UTC
Something that may be related, is the need for some way for the user of streaming data, (either Netflix or YouTube or Skype or Google Talk/Video) to express their bias or preference for EITHER bursty but "full frame" transmission, OR continuous 'Pure' audio transmission with the video degraded in frames per second and/or size of image. In other words, to THROTTLE what is being transmitted by "dumbing it down"
This might allow the Sender to alter the nature of the stream to match the composition of the packets being transmitted to the characteristics of the network
Mon, 04 Jun 2012 12:50:25 UTC
Hm, IPv6 is not adopted, because there have been no thoughts about adopting it (other than "it is magically deployed at once by everybody"). Why should I use IPv6? In my home network, I can do this, but I have just 6 devices connected to each other (all of them IPv6 capable). Hey, for 6 devices, IPv4 is just fine. Hey, on my home network, I don't even need IP, Ethernet is fine. So there's no point.
On the larger net, I have no benefit from adding IPv6. I only have troubles. Tons of them. I need a SiXXs tunnel, because 6to4 is broken in a NAT environment (the only environment, where switching to IPv6 has a potential benefit). Using that, all I can do is reaching the same sites I can reach with IPv4. Therefore, no early adopter likes to start with IPv6. When no early adopter starts using it, there will be no momentum for adaption. Therefore, phase 2 of a rollout never happens. Phase 2 is the most critical, as a significant portion of the population has switched over, while another also significant portion didn't. The whole point of the Internet is to have people communicate with each others, and dual stack is no sane option - if I still absolutely need an IPv4 address, there's no point to getting an IPv6 address.
And phase 3, when the few remaining users who still haven't switched are still supported with their legacy environment (because maybe they can't switch?) is not considered, either.
My experimental protocol currently uses UDP over IPv4 and IPv6 to pass packets around (and as this is just a legacy layer, the internal API doesn't even expose what protocol is used, so it's completely transparent to switch to other transport layers). As it is still in development - it's not yet that much useful. As you can see with other UDP-based protocols like the current BitTorrent protocol, you can replace TCP in some applications quicker than you can replace IPv4. It's a matter of "does it benefit the user". If so, people will adopt it. IPv6 does not give any immediate benefit to the user, *and* it makes transition incredibly hard. People rather use solutions that are useful now (like NAT), even if they make things somewhat more complicated to overcome the limitations of IPv4 instead of switching to IPv6, which makes the assumption that everybody will cooperate. No, nobody cooperates. Wrong social assumptions are just as bad as wrong technical assumptions.
Mon, 23 Jan 2012 13:32:12 UTC
Re: replacing TCP... hehe. It's taken us this long just to start a minimal rollout of IPv6, and you want to replace TCP? See you in the year 3000.. ;-)
What I think deserves more discussion are the OS platforms, and all the 'black box' hardware devices that will remain in service for many years. Whatever is done has to be studiously backwards compatible.
It also doesn't help that some early mechanisms for congestion-control like ICMP 'source quench' messages were deprecated because it was thought that paying-attention to them opened you up to (ie) attack from malicious parties. One would think that with modern encryption/authentication technology we could finally actually _use_ such built-in protocol mechanisms instead of ignoring them because of fear of their misuse by rogue entities.
Van's comment about IPv6 and spreading packet flows amongst a huge number of IP's is definitely food for thought there too.
Mon, 19 Dec 2011 19:58:21 UTC
RDMA over Infiniband and Ethernet should help -- at least for data centers and some variant of the same should help Bit torrent folks.
Sat, 17 Dec 2011 12:24:39 UTC
I'm a bit surprised that this talk pops up just now. I've known about the buffer bloat problem for years (though not under this name), and consider the TCP flow control as fundamentally broken - it was made under the assumption that there is essentially no buffering, which, at that time, was correct, but now is broken.
I've investigating into better flow controls, and first looked at LEDBAT, but LEDBAT is also broken. LEDBAT works if there is a single LEDBAT-controlled data stream through the bottleneck, it can't even manage two. Dan Bernstein's CurveCP is said to be better, but the algorithm lacks a detailed description (it is delay controlled, like LEDBAT, and it's a fairly short algorithm, but it is not well factored out, and the code is written in a typical Dan-Bernstein-"the code is obvious and needs no comments" fashion ;-).
I'm now working on my own flow control, which takes these ideas into account. I'm using an experimental protocol where I can obtain and send around whatever diagnostic data I want - so I'm now packing a ns resolution timestamp into the acknowledge data, which indicates when the receiver actually received the packet. That way I can do a lot more experiments with the algorithm than when I would modify TCP' flow control itself, which can't transmit when the packet arrived (and there may be an arbitrary delay in the acknowledge, which is of no interest for the sender's flow control). This all is tricky, because there is also a receive buffer, i.e. the OS does not pass the first packet immediately to the listener, but queues that up, too.
IMHO, TCP is more broken than just the flow control. It tries to provide three things:
* Flow/bandwidth control
* in-order arrival of the data
* reliability (i.e. retransmission of lost packets)
Modern usage of the Internet often have a different set of requirements. Correct order of packets for file transmission is not needed at all - see BitTorrent, where chunks of the file are transmitted in random order. Reliability, i.e. automatic retransmission is not required either, because the client keeps track of which part of the file are there and which aren't. It should be possible to switch these properties of a protocol on and off, depending on the requirements of the application. Many applications have real-time requirements, for those, flow control mainly is about picking the right resolution for video and the right compression rate for audio (real-time means the sender must fire and forget, and when the bandwidth is not sufficient, adapt by reducing the quality of the data, not by slowing down a HD video stream - this goes beyond the actual network layer; a mobile phone has the bandwidth to receive a full HD video, but it does not have the processing capabilities to play this stream).
And as TCP's flow control is broken under the conditions we have now, this needs fixing, too. To be blunt: I think TCP must be replaced.
Wed, 14 Dec 2011 19:00:33 UTC
This is VERY interesting. Thanks guys for diagnosing the current situation. Van knows how dynamism is the byword for how this has to be addressed. Does he have an algorithm again to be incrementally added to the end points as he intimates that can help those who want to help themselves? Selfishness is what promotes goodness when it comes to improving the commons as we have all learned. Vint is asking vendors to do this in their self interest. But IS there a THIS?
Wed, 14 Dec 2011 10:14:35 UTC
This bufferbloat problem is an indicator that one of the core algorithms supporting Internet was designed ad hoc, without a solid theoretic foundation (of course this is not an easy work). We need sound theory to capture the essence of the reality. Otherwise we will end up with keeping facing such problems again and again when the environment changes. Unfortunately most research in this area so far failed to achieve this goal.
Tue, 13 Dec 2011 16:33:10 UTC
I was pretty young when I toured a switch room and saw a teletype punching paper tape that was falling on the floor, and another teletype tugging that paper tape out of the jumble and sending it along its next hop.
I don't much mind waiting a few seconds while I'm christmas shopping on line. If I were running a research application, deep buffers would annoy me.
Tue, 13 Dec 2011 05:29:52 UTC
Great discussion. I followed most of it, but I didn't understand why local (end user equipment) solutions won't help. Sure they won't be optimal, but if some vendor adds crude dynamic buffer sizing to home units, won't that be useful to both senders and receiver?
Also, for home users what's the right size for down-buffer compared with up-buffer? For example should I always prefer smaller out-buffers measured in MB, due to slower upload speeds and other factors? Again this sounds easy for vendors to implement.
Sat, 10 Dec 2011 02:23:30 UTC
That's just the Queue folks asking for feedback....
Fri, 09 Dec 2011 21:38:00 UTC
I read the all of the previous "Bufferbloat: Dark Buffers in the Internet" article and found it very interesting.
A bit funny how the end line of this one is "LOVE IT, HATE IT? LET US KNOW".
Well obviously I don't love the apparent state of affairs or the gloomy future, but I love how you bright minds seems to be taking a long hard think about it! So, very interesting read this time around as well.
Fri, 09 Dec 2011 01:13:58 UTC
You are correct; that was a mis-statement. But the thrust is correct: Windows XP does not enable TCP Window scaling by default; there is a registry key to turn it on. The thrust is therefore the same: most XP systems won't have more than 64K bytes in flight at once.
Thu, 08 Dec 2011 23:33:53 UTC
You say "That's actually a significant milestone because Windows XP didn't implement window scaling,"
Wikipedia (http://en.wikipedia.org/wiki/TCP_window_scale_option#cite_note-3) says:
"TCP Window Scaling is implemented in Windows since Windows 2000. It is enabled by default in Windows Vista / Server 2008 and newer, but can be turned off manually if required."