On 2007-4-18, at 19:16, ext Colin Perkins wrote:
On 11 Apr 2007, at 23:45, Ian McDonald wrote:On 4/12/07, Gerrit Renker <gerrit@xxxxxxxxxxxxxx> wrote:There is no way to stop a Linux CCID3 sender from ramping X up to the link bandwidth of 1 Gbit/sec; but the scheduler can only control packet pacing up to a rate of s * HZ bytes per second.Let's start to think laterally about this. Many of the problems aroundCCID3/TFRC implementation seem to be on local LANs and rtt is less than t_gran. We get really badly affected by how we do x_recv etc and the rate is basically all over the show. We get affected by send credits and numerous other problems.As a data point, we've seen similar stability issues with our user- space TFRC implementation, although at somewhat larger RTTs (order of a few milliseconds or less). We're still checking whether these are bugs in our code, or issues with TFRC, but this may be a broader issue than problems with the Linux DCCP implementation.
I think Vlad saw similar issues with the KAME code when running over a local area network. (Vlad?)
Lars
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
