| |||||||||||||
Bufferbloat: Dark Buffers in the Internet (ACM Queue)Bufferbloat: Dark Buffers in the Internet (ACM Queue)Posted Dec 6, 2011 16:51 UTC (Tue) by intgr (subscriber, #39733)In reply to: Bufferbloat: Dark Buffers in the Internet (ACM Queue) by marcH Parent article: Bufferbloat: Dark Buffers in the Internet (ACM Queue)
> A 400ms queue does not need to be "actively managed", it just needs to be
> made smaller. No queue should be longer than 100ms, end of.
That's a very interesting point. Much of their work has gone into making queue sizes tunable in bytes, but they're really worried about *latency*, not queue size.
Seems like it could be as simple as tagging each packet with receive timestamps and dropping packets on the draining end if they've been in the queue for too long.
Now I'm sure smarter people than you and I have thought of this and rejected this approach for some reason. Does anyone know why this isn't a good idea?
(Log in to post comments)
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Dec 6, 2011 17:00 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
the problem is that getting the current time is a rather expensive operation, doing this for each packet (and worse, doing it multiple times per packet at different points in the queue), can hurt your network throughput.
in the past, queues have been managed in terms of how many packets are in the queue, not caring if the packet is a 64 byte minimum size packet or a 9000 byte jumbo packet.
one of the results of the bufferbloat effort is the new AQM queue type (I;m blanking on the name of it, but it was merged upstream a release or two ago) that manges the queue size in terms of the size of the queue in bytes, when you have a consistant link speed (i.e. most wired networks), the time needed to transmit each byte is very close to a constant, and so managing the queue in terms of bytes is almost exactly the same as managing it in terms of time.
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Dec 6, 2011 18:40 UTC (Tue) by nix (subscriber, #2304) [Link]
You're thinking of BQL.
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Dec 7, 2011 11:44 UTC (Wed) by mtaht (✭ supporter ✭, #11087) [Link]
dlang: actually, all the work that has gone into making timestamping fast in the last decade seems to have paid off. Eric Dumazet proved to me that it is now incredibly cheap, and I think pursuing "time in queue" has great potential to get us into the sub 30ms range for inherent latencies across a wide range of gear.
I knew in my gut, too, that timestamping was expensive. It *was* - in the early 00s. My gut was wrong.
Milk algorithm? Posted Dec 7, 2011 18:20 UTC (Wed) by dmarti (subscriber, #11625) [Link] Isn't everyone independently coming up with the "milk algorithm?" Here's a carton of milk (packet) with a expiration date. Put it in your fridge (buffer). When you're ready to take it out, compare the expiration date to your current date. If it's not expired, drink it (send it). If it's expired, pour it out.
Milk algorithm? Posted Dec 8, 2011 9:49 UTC (Thu) by mtaht (✭ supporter ✭, #11087) [Link]
Heh. I'm glad there's prior art.
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Jan 2, 2012 10:23 UTC (Mon) by Randakar (guest, #27808) [Link]
Even if putting a timestamp on packets is too expensive for each individual packet, there are ways to mitigate that.
For example, a queue manager could put a magic timestamp packet in it's queue at periodic intervals. Say, 0.1 ms. (This number may need tuning..)
Every time a timestamp packet hits the front of the queue all packets behind it until the next timestamp marker will be at least (timestamp + something less than 1 interval) old. If that timestamp is too old you just drop the packets in the interval and move on.
Of course this solution isn't as good as individual timestamps - you can still get into situations where you're sending very old packets because there are too many packets in the intervals that you ARE processing - but I can imagine cases where this type of tradeoff may be worthwhile.
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Jan 3, 2012 13:01 UTC (Tue) by etienne (subscriber, #25256) [Link]
Or use 16 queues organised by received time to store packets, at some point queue (head) No 6 contains new packets currently arriving, it you are still sending packets from queue (tail) No 7 then throw away the whole queue No 7.
Next timeslot store new packets in queue No 7 and throw away queue No 8.
|
|||||||||||||