[Bloat] Goodput fraction w/ AQM vs bufferbloat

[Richard Scheffenegger]

I think a definition of terms would be in order. For me:

goodput: number of bytes delivered at the receiver to the next upper layer 
application, per unit of time
throughput: number of bytes send by the sender, into the network, per unit 
of time

Thus goodput can be a ratio (delivered bytes on the receiving application 
vs. data bytes sent by the sender's TCP), but by definition, only a 
completely loss-less, in-order stream of segments can ever hope of achiving 
that; any instance of fast recovery, retransmission timeout etc, and the 
goodput fraction will always be (much) less than 100%. (However, fringe 
effects like ssthresh reset for idle connections won't influence that 
fraction at all, but may lower the absolute values).

Charging for volume without considering the goodput fraction, is like 
overpaying - if the publing would work properly, you (end customer, 
small/medium ISP) would get charged for the real work you demanded of the 
network (data bytes delivered to a receiving application). Since the 
plumbing is broken, you get charged for the brokenness also (because only 
absolut data volume is counted), giving less than zero incentive to those 
who could fix the plumbing to do it.


Exposing this brokenness is one of the nice properties of CONEX - upstream 
ISPs can be graded by the congestion they cause (or are willing to 
tolerate), and customers are empowered to make a concious choice to use an 
ISP which may be charge more (say 2%) per volume of data, but where the 
goodput fraction is at least a similar percentage points better... I.e. by 
properly tuning their AQM schemes.

Best regards,
   Richard


----- Original Message ----- 
From: "richard" <richard at pacdat.net>
To: "Fred Baker" <fredbakersba at gmail.com>
Cc: <bloat at lists.bufferbloat.net>
Sent: Friday, May 06, 2011 5:14 PM
Subject: Re: [Bloat] Goodput fraction w/ AQM vs bufferbloat


> I'm wondering if we should look at the ratio of throughput to goodput
> instead of the absolute numbers.
>
> Yes, the goodput will be 100% but at what cost in actual throughput? And
> at what cost in total bandwidth?
>
> If every packet takes two attempts then the ratio will be 1/2 - 1 unit
> of googput for two units of throughput (at least up to the choke-point).
> This is worst-case, so the ratio is likely to be something better than
> that 3/4, 5/6, 99/100 ???
>
> Hmmm... maybe inverting the ratio and calling it something flashy (the
> bloaty rating???) might give us a lever in the media and with ISPs that
> is easier for the math challenged to understand. Higher is worse.
>
> Putting a number to this will also help those of us trying to get ISPs
> to understand that their Usage Based Bilking (UBB) won't address the
> real problem which is hidden in this ratio. The fact is, the choke point
> for much of this is the home router/firewall - and so that 1/2 ratio
> tells me the consumer is getting hosed for a technical problem.
>
> richard
>
> On Thu, 2011-05-05 at 21:18 -0700, Fred Baker wrote:
>> There are a couple of ways to approach this, and they depend on your 
>> network model.
>>
>> In general, if you assume that there is one bottleneck, losses occur in 
>> the queue at the bottleneck,
>> and are each retransmitted exactly once (not necessary, but helps), 
>> goodput should approximate 100%
>> regardless of the queue depth. Why? Because every packet transits the 
>> bottleneck once - if it is
>> dropped at the bottleneck, the retransmission transits the bottleneck. So 
>> you are using exactly
>> the capacity of the bottleneck.
>>
>> the value of a shallow queue is to reduce RTT, not to increase or 
>> decrease goodput. cwnd can become
>> too small, however; if it is possible to set cwnd to N without increasing 
>> queuing delay, and cwnd is
>>  less than N, you're not maximizing throughput. When cwnd grows above N, 
>> it merely increases queuing
>>  delay, and therefore bufferbloat.
>>
>> If there are two bottlenecks in series, you have some probability that a 
>> packet transits one
>> bottleneck and doesn't transit the other. In that case, there is probably 
>> an analytical way
>> to describe the behavior, but it depends on a lot of factors including 
>> distributions of competing
>>  traffic. There are a number of other possibilities; imagine that you 
>> drop a packet, there is a
>> sack, you retransmit it, the ack is lost, and meanwhile there is another 
>> loss. You could easily
>> retransmit the retransmission unnecessarily, which reduces goodput. The 
>> list of silly possibilities
>>  goes on for a while, and we have to assume that each has some 
>> probability of happening in the wild.
>>
> snip...
>
> richard
>
> -- 
> Richard C. Pitt                 Pacific Data Capture
> rcpitt at pacdat.net               604-644-9265
> http://digital-rag.com          www.pacdat.net
> PGP Fingerprint: FCEF 167D 151B 64C4 3333  57F0 4F18 AF98 9F59 DD73
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat