Stuff I'm reading on a Friday afternoon

A couple interesting things to keep you at your computer on a warm spring day!

• Kathie Nichols and Van Jacobson's recent article in ACM Queue has spurred a lot of interesting discussion. Here's some of what I've seen so far:
  • Jim Gettys is hailing the work as Fundamental Progress Solving Bufferbloat, and notes that

    A preliminary Linux implementation of CoDel written by Eric Dumazet and Dave Täht is now being tested on Ethernet over a wide range of speeds up to 10gigE, and is showing very promising results similar to the simulation results in Kathie and Van’s article.

  • Not everybody is so happy about the new queue management proposal. Bram Cohen, in particular, lit into it with a strongly-worded article, TCP Sucks

    For the end user to complain about how big the buffer is would be like them complaining to their credit card company for offering too high of a limit. ‘You should have known I’d spend too much!’ The solution is for the end user to intervene, and tell all their applications to not be such pigs, and use uTP instead of TCP.

  • Avery Pennarun added his own thoughts in an interesting article: TCP doesn't suck, and all the proposed bufferbloat fixes are identical.

    Oddly enough, fixing TCP to work around bufferbloat is pretty easy. The solution is "latency-based TCP congestion control," the most famous implementation of which is TCP Vegas. Sadly, when you run it or one of its even better successors, you soon find out that old-style TCP always wins, just like it always wins over uTP, and for exactly the same reason. That means, essentially, that if anyone on the Internet is sharing bandwidth with you (they are), and they're running traditional-style TCP (virtually everyone is), then TCP Vegas and its friends make you a sucker with low speeds. Nobody wants to be a sucker.

  • And Matthew Sackman from the RabbitMQ team has yet another perspective: Some queuing theory: throughput, latency and bandwidth.

    it's possible to see reasons why CoDel isn't as appropriate for dealing with AMQP messages as it is for plain IP. It's also worth remembering that requeuing messages via nacks is a fairly expensive operation, so it's a good idea to set the parameters of CoDel to ensure in normal operation very few if any messages are being nacked.

• Separately, I've also been looking through a series of recent articles by the team at BlueBox.net:
  • Distributed Systems Design (part 1/4)
  • Distributed Systems Design (Part 2/4)
  • Distributed Systems Design (Part 3/4)
  • Distributed Systems Design (Part 4/4)

  This document was written with the goal of giving you a place to start to understand the concepts and concerns involved, as well as to give some practical advice as to “where to start” if you are trying to turn an application which exists happily in a single datacenter into an application which exists happily spread across two or more data centers.

See, there you go! More things to read, to get smarter!