| |||||||||||||
The CHOKe packet schedulerThe CHOKe packet schedulerPosted Jan 13, 2011 19:53 UTC (Thu) by njs (guest, #40338)In reply to: The CHOKe packet scheduler by marcH Parent article: The CHOKe packet scheduler
> Bufferbloat is quite obviously about unreasonable queue sizes (more than 10 milliseconds), while CHOKe or RED should also apply to manage queues of reasonable size
Bufferbloat is about unreasonable *average* queue sizes; if you receive 100 ms worth of traffic in a lump every 100 ms, then you aren't oversubscribed at all, and the right thing to do is to buffer all of it. (In general, the proper queue size grows with the RTT of the flows, which may be *way* above 10 ms.) So it makes sense to have a reasonably large queue; the point of AQM algorithms is to make sure that this queue is only used to smooth out burstiness, instead of becoming a simple delay line.
IIUC.
(Log in to post comments)
The CHOKe packet scheduler Posted Jan 13, 2011 22:07 UTC (Thu) by marcH (subscriber, #57642) [Link]
If you receive 100 ms worth of traffic in a lump and buffer them all then the last packets to go out will suffer a 100 ms extra delay (just on this link!). Unless you do not care a bit about latency, you do not want that. What you want is to drop a large number of these packets so a similar burst does not happen again.
Note: since TCP is ACK-clocked, it is not bursty at all.
> In general, the proper queue size grows with the RTT of the flows,
I do not see why. The RTT matters only for end to end buffers.
The CHOKe packet scheduler Posted Jan 13, 2011 22:55 UTC (Thu) by Shewmaker (subscriber, #1126) [Link]
> Note: since TCP is ACK-clocked, it is not bursty at all.
How do you define a burst? If it is more than one packet
Of course, a qdisc or something at a lower level may
The CHOKe packet scheduler Posted Jan 14, 2011 6:48 UTC (Fri) by marcH (subscriber, #57642) [Link]
> How do you define a burst? If it is more than one packet
sent without waiting between them, then isn't the window size of a TCP connection its burst size?
TCP does not send a receive window size at a time because it is also constantly limited by the congestion window. Sending is then regulated by the reception of ACK (one every two packets).
So a (single!) TCP connection is practically never bursty in normal conditions.
The CHOKe packet scheduler Posted Jan 14, 2011 2:20 UTC (Fri) by njs (guest, #40338) [Link]
> If you receive 100 ms worth of traffic in a lump and buffer them all then the last packets to go out will suffer a 100 ms extra delay (just on this link!). Unless you do not care a bit about latency, you do not want that. What you want is to drop a large number of these packets so a similar burst does not happen again.
Dropping packets tells the sender to slow down. But in this case, the sender is already sending at the proper speed! You don't want them to reduce throughput, you just want them to smooth out their sending. But dropping packets doesn't tell them to do that, it just tells them to slow down.
Note that if they smoothed out their sends, so you got 1 ms of traffic every 1 ms, then that last packet would just get sent 100 ms later. There's no unnecessary latency being added here.
> I do not see why.
To tell the truth, I'm not sure either, but I'm quoting Van Jacobson et al (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2...) so I believe it. Perhaps someone will come along shortly to explain better.
The CHOKe packet scheduler Posted Jan 14, 2011 6:53 UTC (Fri) by marcH (subscriber, #57642) [Link]
> Dropping packets tells the sender to slow down. But in this case, the sender is already sending at the proper speed! You don't want them to reduce throughput, you just want them to smooth out their sending. But dropping packets doesn't tell them to do that, it just tells them to slow down.
TCP sending is smooth by design, check the literature.
If it is not TCP, yes you are right this might be too drastic and harm throughput. But it's only because your application does not behave. And it will preserve latency. And the bandwidth lost by killing the burst might be reused by better behaved applications.
The CHOKe packet scheduler Posted Jan 14, 2011 9:03 UTC (Fri) by marcH (subscriber, #57642) [Link]
> If it is not TCP, yes you are right this might be too drastic and harm throughput. But it's only because your application does not behave.
By the way, if you need to smooth UDP-like traffic then DCCP has been designed expressly for you (Datagram Congestion Control Protocol).
|
|||||||||||||