Actually, fq_codel's sparse flow optimization provides a pretty strong
incentive for pacing traffic.

If your TCP traffic is well paced, and is running at a rate below that of
the bottleneck, then it will not build a queue.

It will then be recognized as a "good guy" flow, and scheduled
preferentially against other TCP flows that do build a queue (which is what
happens today, with TCP's without pacing).
                                                  - Jim


On Wed, Apr 22, 2015 at 10:05 AM, Bill Ver Steeg (versteb) <
versteb@cisco.com> wrote:

> Actually, pacing does provide SOME benefit even when there are AQM schemes
> in place. Sure, the primary benefit of pacing is in the presence of legacy
> buffer management algorithms, but there are some additional benefits when
> used in conjunction with a modern queue management scheme.
>
> Let's conduct a mind experiment with two rate adaptive flows competing at
> a bottleneck neck on a very simple one hop network with very short RTT. The
> results map into your topology of choice. As in most rate adaptive
> protocols, there are N rates available to the receiver. The receiver
> fetches a chunk of data, observes the receive rate and decides the
> resolution of the next chunk of data that it fetches. It up shifts and down
> shifts based on perceived network conditions.
>
>
> First, the unpaced version
> On the idle link, let's start both flows - with a small offset in time
> between them. The first flow will HTTP get a small chunk of data at a very
> low resolution, and will get the data at the line rate. The second one will
> then get a small chunk of data at a very low resolution, and will also get
> the data at the line rate. What will each adaptive bitrate algorithm think
> the available BW is? They will both think they can run at the line
> rate...... They both decide to upshift to a higher rate. Maybe they go to
> the next resolution up, maybe they go to just below the line rate. Rinse
> and repeat at various rates, with the square wave receiving patterns
> overlapping anywhere from 0% to 100%. When the flows do not 100% overlap in
> time, each client overestimates the link capacity. So,  the apparent rate
> (as seen by the adaptation logic on the client) is misleading.
>
> Now the paced version
> On the idle link, let's start both flows- with a small offset in time
> between them. The first flow gets a small chunk of data at a very low
> resolution, but the data is paced at certain rate (could be the next higher
> rate in the manifest file for this asset, could be the highest rate in the
> manifest file, could be 1.x times one of these rates, could be some other
> rate....). The second one will then get a small chunk of data at a very low
> resolution, also  at a deterministic paced rate.  The data will arrive at
> the client at either the rate they requested or slower. The flows tend to
> be dispersed in time, and "defend their turf" a bit. The likelihood of a
> gross mis-estimation of spare link capacity is decreased.
>
> Note that this is definitely a second-order effect, and one has to think
> about how such flows compete against the more aggressive "send as fast as
> you can" algorithms. It seems that there would be a control theory approach
> to solving this problem. Hopefully somebody with better math skills then me
> could quantify the effects.
>
> There is a bit of game theory mixed into the technical analysis. I have
> been playing around with this a bit, and it is (at the very least) quite
> interesting....
>
>
> Bill Ver Steeg
> DISTINGUISHED ENGINEER
> versteb@cisco.com
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: bloat-bounces@lists.bufferbloat.net [mailto:
> bloat-bounces@lists.bufferbloat.net] On Behalf Of Steinar H. Gunderson
> Sent: Wednesday, April 22, 2015 12:00 PM
> To: luca.muscariello@orange.com
> Cc: bloat
> Subject: Re: [Bloat] RE : DSLReports Speed Test has latency measurement
> built-in
>
> On Wed, Apr 22, 2015 at 03:26:27PM +0000, luca.muscariello@orange.com
> wrote:
> > BTW if a paced flow from Google shares a bloated buffer with a non
> > paced flow from a non Google server,  doesn't this turn out to be a
> > performance penalty for the paced flow?
>
> Nope. The paced flow puts less strain on the buffer (and hooray for that),
> which is a win no matter if the buffer is contended or not.
>
> > fq_codel gives incentives to do pacing but if it's not deployed what's
> > the performance gain of using pacing?
>
> fq_codel doesn't give any specific incentive to do pacing. In fact, if
> absolutely all devices on your path would use fq_codel and have adequate
> buffers, I believe pacing would be largely a no-op.
>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>