Re: [Bloat] Burst Loss

[Neil Davies <Neil.Davies@pnsol.com>]

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


On 6 May 2011, at 12:40, Sam Stickland wrote:

> 
> 
> 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?


It is a device in the network, it sits at the 'edge' of the access network (at the ISP / Network Wholesaler boundary) - that resolves the downstream issue.

Neil

> 
> Sam


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