Re: [Bloat] Burst Loss

[Sam Stickland <sam@spacething.org>]

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]



On 5 May 2011, at 17:49, Neil Davies <Neil.Davies@pnsol.com> wrote:

> On the issue of loss - we did a study of the UK's ADSL access network back in 2006 over several weeks, looking at the loss and delay that was introduced into the bi-directional traffic.
> 
> We found that the delay variability (that bit left over after you've taken the effects of geography and line sync rates) was broadly
> the same over the half dozen locations we studied - it was there all the time to the same level of  variance and that what did vary by time of day was the loss rate.
> 
> We also found out, at the time much to our surprise - but we understand why now, that loss was broadly independent of the offered load - we used a constant data rate (with either fixed or variable packet sizes) .
> 
> We found that loss rates were in the range 1% to 3% (which is what would be expected from a large number of TCP streams contending for a limiting resource).
> 
> As for burst loss, yes it does occur - but it could be argued that this more the fault of the sending TCP stack than the network.
> 
> This phenomenon was well covered in the academic literature in the '90s (if I remember correctly folks at INRIA lead the way) - it is all down to the nature of random processes and how you observe them.  
> 
> Back to back packets see higher loss rates than packets more spread out in time. Consider a pair of packets, back to back, arriving over a 1Gbit/sec link into a queue being serviced at 34Mbit/sec, the first packet being 'lost' is equivalent to saying that the first packet 'observed' the queue full - the system's state is no longer a random variable - it is known to be full. The second packet (lets assume it is also a full one) 'makes an observation' of the state of that queue about 12us later - but that is only 3% of the time that it takes to service such large packets at 34 Mbit/sec. The system has not had any time to 'relax' anywhere near to back its steady state, it is highly likely that it is still full. 
> 
> Fixing this makes a phenomenal difference on the goodput (with the usual delay effects that implies), we've even built and deployed systems with this sort of engineering embedded (deployed as a network 'wrap') that mean that end users can sustainably (days on end) achieve effective throughput that is better than 98% of (the transmission media imposed) maximum. What we had done is make the network behave closer to the underlying statistical assumptions made in TCP's design.

How did you fix this? What alters the packet spacing? The network or the host?

Sam

[-- Attachment #2: Type: text/html, Size: 3594 bytes --]