| |||||||||||||
The CHOKe packet schedulerThe CHOKe packet schedulerPosted Jan 13, 2011 22:07 UTC (Thu) by marcH (subscriber, #57642)In reply to: The CHOKe packet scheduler by njs Parent article: The CHOKe packet scheduler
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.
(Log in to post comments)
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).
|
|||||||||||||