Re: [Bloat] Best practices for paced TCP on Linux?

["Steinar H. Gunderson" <sgunderson@bigfoot.com>]

On Sat, Apr 07, 2012 at 04:08:20PM +0100, Neil Davies wrote:
> That is the general idea - the issue is that the dynamic arrival rate as
> "round trip window size" double just dramatically exceeds the available
> buffering at some intermediate point  - it is self inflicted (intra stream)
> congestion with the effect of dramatically increasing the quality
> attenuation (delay and loss) for streams flowing through that point.

We've been tuning our stream to have more consistent frame sizes (adjusting
the VBV settings); that seems to have alleviated the problems somewhat.

> The packet train may also be an issue, especially if there is h/w assist
> for TCP (which might well be the case here, as the interface was  a 10G
> one, comments Steinar?) - we have observed an interesting phenomena in
> access networks where packet trains arrive (8+ packets back to pack at 10G)
> for service down a low speed (2M) link - this leads to the effective
> transport delay being highly non-stationary - with all that implies for the
> other flows on that link.

The card is a standard Intel 10GigE card, and we've turned off segmentation
offload to avoid this precise issue.

I've also tried hacking VLC to pace out the packets a bit more, but it didn't
really seem to give the effect I had hoped, especially as things sometimes
would glitch even without any packets actually being lost (which would
contradict my “10GigE is too bursty” guess). The VBV tuning was a lot more
efficient.

/* Steinar */
-- 
Homepage: http://www.sesse.net/