Subject: [aqm] Gathering Queue Length Statistics

From: Ryan Doyle <[email-masked]>
Date: Wed, 25 Feb 2015 12:53:29 -0500

Hello,

I am a senior undergraduate student at the University of North Carolina at Chapel Hill and am studying the effectiveness of AQMs. I have set up a lab network and plan on running different sets of experiments with different AQMs. My router machines are running Linux kernel version 3.16.0.

I am using the fq_codel, codel, and pie qdiscs for my research and am wondering if there is a way to collect statistics regarding the average queue length since a qdisc was enabled? I have looked at tc's "-s" flag for statistics, but they show nothing about queue length and I have been unable to find anything else that might help me get queue length statistics.

Best,
Ryan Doyle

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 25 Feb 2015 18:20:33 +0000

I'd suggest looking at netperf. It doesn't measure the queue directly; it measures the latency that queue occupancy induces. However, at least in commercial equipment, this thing we call "the queue" may not be all in the same place...

________________________________
From: aqm [[email-masked]] on behalf of Ryan Doyle [[email-masked]]
Sent: Wednesday, February 25, 2015 9:53 AM
To: [email-masked]
Subject: [aqm] Gathering Queue Length Statistics

Hello,

Best,
Ryan Doyle

---

From: Dave Taht <[email-masked]>
Date: Wed, 25 Feb 2015 10:24:45 -0800

On Wed, Feb 25, 2015 at 9:53 AM, Ryan Doyle <[email-masked]> wrote:
> Hello,
>
> I am a senior undergraduate student at the University of North Carolina at
> Chapel Hill and am studying the effectiveness of AQMs. I have set up a lab
> network and plan on running different sets of experiments with different
> AQMs. My router machines are running Linux kernel version 3.16.0.
>
> I am using the fq_codel, codel, and pie qdiscs for my research and am
> wondering if there is a way to collect statistics regarding the average
> queue length since a qdisc was enabled? I have looked at tc's "-s" flag for
> statistics, but they show nothing about queue length and I have been unable
> to find anything else that might help me get queue length statistics.

Oh, god. I am getting incredibly sensitive about average queue length,
and I realize that that is not what you meant. But since not enough
people have seemingly read this or any of the related materials, here
it is again.

http://www.pollere.net/Pdfdocs/QrantJul06.pdf

And I of course always recommend van´s talk on the fountain model for
thinking about closed loop servo systems.

http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos

In the bufferbloat project...

We have developed many tools that drive aqms hard, see netperf-wrapper
on github for that, which measures e2e delay without requiring any
tools on the routers inbetween. e2e delay in my mind is way more
important than average queue length. And you can derive the queue
length(s) from tcp timestamps in those netperf-wrapper tests, from
additional packet captures, if you must.

If you absolutely MUST derive average queue length from the box, you
can poll the interface frequently with tc -s qdisc show as well as
with ifconfig- and parse out the number of packets and the number of
bytes. But you can do MUCH more valid statistical analysis than that,
with that sort of data set - and if you poll too frequently you will
heisenbug your tests, as those data collection calls take locks that
interfere with the path. and we have all sorts of advice about traps
for the unwary here:

http://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel

Please use things like CDFs to see the range of delays, rather than
averages. It is what happens at above 90% of the range that makes
bufferbloat maddening to ordinary users.

I am summarily rejecting any papers that I review that report average
queue length as if it meant anything. And for a few other reasons. You
have been warned. I really lost my temper after the last paper I
reviewed last weekend and the resulting flamage is all over the bloat
list and codel lists, and starts here:

https://lists.bufferbloat.net/pipermail/codel/2015-February/000872.html

> Best,
> Ryan Doyle
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

---

From: Daniel Havey <[email-masked]>
Date: Wed, 25 Feb 2015 11:16:40 -0800

Jeez Dave, don't scare the kid!  :^)  He's only an undergrad!

Look Ryan, Dave really does have your best interest at heart and that is why he wants you to use CDFs instead of averages.  And he is right, I think you should use CDFs also.  In fact, save yourself a pile of repetitve work and just use Toke's tools.  They will produce better results and require less work from you :)

Trust me on this.  I have done both and Toke's tools are waaaaay better and easier than anything you (or I) will come up with.  Install Toke's tools and then you will have a cornucopia of awesome and repeatable results that you can just plug in to your final paper.  Go for it :^)

thanxs ;^)
...Daniel

--------------------------------------------
On Wed, 2/25/15, Dave Taht <[email-masked]> wrote:

 Subject: Re: [aqm] Gathering Queue Length Statistics
 To: "Ryan Doyle" <[email-masked]>
 Cc: "[email-masked]" <[email-masked]>
 Date: Wednesday, February 25, 2015, 10:24 AM
 
 On Wed, Feb 25, 2015 at
 9:53 AM, Ryan Doyle <[email-masked]>
 wrote:
 > Chapel
 Hill and am studying the effectiveness of AQMs. I have set
 up a lab
 > network and plan on running
 different sets of experiments with different
 > wondering
 if there is a way to collect statistics regarding the
 average
 > queue length since a qdisc was
 enabled? I have looked at tc's "-s" flag
 for
 > statistics, but they show nothing
 about queue length and I have been unable
 > to find anything else that might help me
 get queue length statistics.
 
 Oh, god. I am getting incredibly sensitive
 about average queue length,
 and I realize
 that that is not what you meant. But since not enough
 people have seemingly read this or any of the
 related materials, here
 it is again.

 And I of course always
 recommend van´s talk on the fountain model for
 thinking about closed loop servo systems.

 In the bufferbloat
 project...
 
 We have
 developed many tools that drive aqms hard, see
 netperf-wrapper
 on github for that, which
 measures e2e delay without requiring any
 tools on the routers inbetween. e2e delay in my
 mind is way more
 important than average
 queue length. And you can derive the queue
 length(s) from tcp timestamps in those
 netperf-wrapper tests, from
 additional
 packet captures, if you must.
 
 If you absolutely MUST derive average queue
 length from the box, you
 can poll the
 interface frequently with tc -s qdisc show as well as
 with ifconfig- and parse out the number of
 packets and the number of
 bytes. But you can
 do MUCH more valid statistical analysis than that,
 with that sort of data set - and if you poll
 too frequently you will
 heisenbug your
 tests, as those data collection calls take locks that
 interfere with the path. and we have all sorts
 of advice about traps
 for the unwary
 here:

 Please use
 things like CDFs to see the range of delays, rather than
 averages. It is what happens at above 90% of
 the range that makes
 bufferbloat maddening
 to ordinary users.
 
 I am
 summarily rejecting any papers that I review that report
 average
 queue length as if it meant
 anything. And for a few other reasons. You
 have been warned. I really lost my temper after
 the last paper I
 reviewed last weekend and
 the resulting flamage is all over the bloat
 list and codel lists, and starts here:

 
 -- 
 Dave
 Täht
 Let's make wifi fast, less jittery
 and reliable again!

---

From: Jesper Dangaard Brouer <[email-masked]>
Date: Thu, 26 Feb 2015 10:15:12 +1300

Hi Ryan,

Follow Daniel's advice, just use netperf-wrapper. I wrote an easy setup
guide for netperf-wrapper here:
 http://netoptimizer.blogspot.co.nz/2014/09/mini-tutorial-for-netperf-wrapper-setup.html

You will love the GUI mode:
 netperf-wrapper --gui

Most powerful thing in the GUI is that you can easy "load" result sets
on-top-of each-other, which allow you to easy compare. And you can save
these as PNG and add them easily to your report :-)

And the secret to (solving) bufferbloat is not the queue length, but
the time-spend in the queue, which is actually easier to derive ;-) 

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

On Wed, 25 Feb 2015 11:16:40 -0800 Daniel Havey <[email-masked]> wrote:

> Look Ryan, Dave really does have your best interest at heart and that
> is why he wants you to use CDFs instead of averages.  And he is
> right, I think you should use CDFs also.  In fact, save yourself a
> pile of repetitve work and just use Toke's tools.  They will produce
> better results and require less work from you :)
> 
> Trust me on this.  I have done both and Toke's tools are waaaaay
> better and easier than anything you (or I) will come up with.
> Install Toke's tools and then you will have a cornucopia of awesome
> and repeatable results that you can just plug in to your final
> paper.  Go for it :^)
> 
> thanxs ;^)
> ...Daniel
> 
> 

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

---

From: Dave Taht <[email-masked]>
Date: Wed, 25 Feb 2015 15:00:05 -0800

>  http://netoptimizer.blogspot.co.nz/2014/09/mini-tutorial-for-netperf-wrapper-setup.html

In looking at your tutorial I note that netperf in svn has added a new
EXTREMELY nice feature (that netperf-wrapper does not use yet),
notably

d@nuc-client:~/git/netperf$ DUMP_TCP_INFO=1 netperf -H 172.21.2.1
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
172.21.2.1 () port 0 AF_INET : demo
tcpi_rto 202000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 29200
tcpi_rtt 1558 tcpi_rttvar 290 tcpi_snd_ssthresh 52 tpci_snd_cwnd 54
tcpi_reordering 3 tcpi_total_retrans 7
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.03     320.94

So I would kind of recommend using the svn version rather than the 2.6
version at this point. (big thanks to eric dumazet for the suggestion)

I also note that netperf-wrapper has a man page, which apparently a
few have missed.

Patches are always welcomed to improve the documentation. Also there
are a whole bunch of new tests that I would like to add (or prefer!
find people to write and add) involving wrapping a few other tools
that are easier to use and more robust than dit-g, which I can write
up specs for up here if anyone is interested... and some new stuff for
wifi.

and I have a new analytical model for looking the bifurcation
characteristics of multiple flows moving in and out of slow start...
(but I will be damned if I publish the core ideas at the moment, or
explain less obliquely, as I hope to finally get a paper out of it in
collaboration with someone willing to do the experiments. :)
Volunteers?

)

> these as PNG and add them easily to your report :-)

I so love being able to compare noisy data from multiple test runs...

And I tend to use .svgs or .eps or .pdf rather than .pngs as you
capture more scalable detail that works better at multiple
resolutions. At least some latex tools can deal with that well.

> the time-spend in the queue, which is actually easier to derive ;-)

+10, but it is mildly more tricky than that. ;)

---

From: grenville armitage <[email-masked]>
Date: Thu, 26 Feb 2015 15:19:15 +1100

On 02/26/2015 04:53, Ryan Doyle wrote:
	[..]
> wondering if there is a way to collect statistics regarding the
> average queue length since a qdisc was enabled? I have looked at tc's
> "-s" flag for statistics, but they show nothing about queue length
> and I have been unable to find anything else that might help me get
> queue length statistics.

Perhaps off on a tangent, but you might find http://caia.swin.edu.au/tools/spp/ a useful complement to your measurements. If you tcpdump the packets going in and out either side of your router, spp can take the two dump files and estimate the instantaneous RTT (itself a reflection of instantaneous queue depth) over time between said router ports. Use this to validate/contrast with RTT estimates you extract from TCP timestamps.

cheers,
gja

---

From: Ryan Doyle <[email-masked]>
Date: Wed, 25 Feb 2015 23:40:31 -0500

Thank you very much for taking the time to write your response and link me to the resources. 

I am planning on creating CDFs and have no intention of using average queue length as a primary statistic in my research. I am putting much more emphasis on end to end delays. That said, I am interested in taking sample measurements of instantaneous queue length, but am really looking for any queue-length statistics the AQMs may measure.

Best,
Ryan Doyle

p.s. Thank you to everyone else that responded as well. I will be sure to look at all of the links, but can't respond to everything individually.

> Date: Wed, 25 Feb 2015 10:24:45 -0800
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 26 Feb 2015 11:30:00 +0100 (CET)

On Wed, 25 Feb 2015, Dave Taht wrote:

> people have seemingly read this or any of the related materials, here it 
> is again.

But it would be valuable to see "instant current length" and other types 
of statistics if they were collected once per second and the per-second 
values were kept for 30 values back in time (ie 30 seconds worth of data)?

I know some commercial routers will have the possibility of showing the 
current percentage queue fill on the device. I don't know how the Linux 
AQM system works, but exposing some of these counters through the proc 
subsystem (or something else), might work, and then a userspace daemon 
could poll this data as often as it wanted, then you don't even need the 
kernel to do averaging and keeping the data.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 26 Feb 2015 11:36:03 +0100

Mikael Abrahamsson <[email-masked]> writes:

> I don't know how the Linux AQM system works, but exposing some of
> these counters through the proc subsystem (or something else), might
> work, and then a userspace daemon could poll this data as often as it
> wanted, then you don't even need the kernel to do averaging and
> keeping the data.

It's exposed via the Netlink interface, which is what `tc -s` shows:

qdisc fq_codel 110: dev enp2s0 parent 1:10 limit 1000p flows 1014 quantum 500 target 5.0ms interval 100.0ms ecn 
 Sent 16981968691 bytes 17816348 pkt (dropped 8, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
  maxpacket 13216 drop_overlimit 0 new_flow_count 6502039 ecn_mark 0
  new_flows_len 1 old_flows_len 5

The 'backlog 0b 0p' shows that the queue is currently empty, while the
lines below show qdisc-specific stats. But as Dave said, getting the
statistics has some locking issues that may (or will, probably) cause
trouble if trying to poll it too frequently...

-Toke

---

From: Daniel Havey <[email-masked]>
Date: Thu, 26 Feb 2015 19:44:18 +0000 (UTC)

I know that this question is a bit ridiculous in this community.  Of course bufferbloat is a real problem.  However, it would be nice to formally address the question and I think this community is the right place to do so.

Does anybody have a measurement study?  I have some stuff from the FCC Measuring Broadband in America studies, but, that doesn't address bufferbloat directly.

Let me repeat for clarity.  I don't need to be convinced.  I need evidence that I can use to convince my committee.

...Daniel

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 27 Feb 2015 13:52:39 -0500

In message <[email-masked]>
Daniel Havey writes:
 
>  
> I know that this question is a bit ridiculous in this community.  Of
> course bufferbloat is a real problem.  However, it would be nice to
> formally address the question and I think this community is the right
> place to do so.
>  
> Does anybody have a measurement study?  I have some stuff from the FCC
> Measuring Broadband in America studies, but, that doesn't address
> bufferbloat directly.
>  
> Let me repeat for clarity.  I don't need to be convinced.  I need
> evidence that I can use to convince my committee.
>  
> ...Daniel
>  

Daniel,

You are convinced.  So am I but we need to temper the message to avoid
going too far in the opposite direction - too little buffer.

If you are not interested in the details, just skip to the last
paragraph.

Bufferbloat should in principle only be a problem for interactive
realtime traffic.  Interactive means two way or multiway.  This is
SIP, Skype, audio and video conferencing, etc.  In practice it is also
bad for TCP flows with short RTT and max window set small.

One way realtime (such as streaming audio and video) should be
unnafected by all but huge bufferbloat.  That is should be.  For
example, youtube video is carried over TCP and is typically either way
ahead of the playback or choppy (inadequate aggregate bandwidth or
marigninal and/or big drop with TCP stall).  It would be nice if
marginal aggregate bandwidth was dealt with by switching to a lower
bandwidth encoding, but too often this is not the case.  This doesn't
mean that some streaming formats don't manage to get this wrong and
end up delay sensitive.

TCP needs buffering to function correctly.  Huge bufferbloat is bad
for TCP, particularly for small transfers that never get out of TCP
slow start and for short RTT flows.  For long RTT flows too little
buffer causes problems.

[ aside: For example, if TCP starts with 4 segments at 1K segment
size, it will take 4 RTT to hit 64KB window, the typical max window
without TCP large window (TCPLW) option.  During that time, 60KB will
be sent.  After that 64KB will be sent each RTT.  With geographic RTT
is 70 msec (approximate US continental RTT due to finite speed of
light in fiber and fiber distance), 60 KB is sent in the first 280
msec and 64KB gets sent every 70 msec yielding 7 mb/s.  OTOH if there
is a server 2 msec RTT away (1 msec one way is 125mi = 200km), then
60KB in first 8 msec and 256 Mb/s after that.  If there is 100 msec
buffer at a bottleneck, then this low RTT TCP flow will be slowed by a
factor of 50.  OTOH, if bottlenecks have a lot less than 1 RTT of
buffer, then the long TCP flows will get even further slowed. ]

One of the effects of some buffer, but not excessive, is short RTT
flows which given the no-TCPLW max window get slowed down while longer
RTT are less affected.  This becomes more fair wrt to transfer rates
among TCP flows.  The same holds true if TCPLW gets turned on in
commodity gadgets and the commonly deploed max window increases, but
the number change.

If the buffer grows a little and the deployed window sizes become the
limiting factor, then this is very light congestion with delay but
absolutely zero loss due to queue drops (not considering AQM for the
moment).

Some uses of TCP increase the window to work better over long RTT.  It
takes a bit longer to hit the max window but the rate once it has been
hit is greater.  Setting TCP window large on short RTT flows is
counterproductive since one or a small number of flows can cause a
bottleneck on a slow provider link (ie: 10-100 Mb/s range typical of
home use).  On a LAN RTT can be well under 1 msec on Ethernet and
highly variable on WiFi.  On WiFi larger window can contribute to some
real trouble.  So best that the default window be changed.  

[ Note that the work on automatic sizing of tcp_sndbuf and scp_recvbuf
may create a tendency to saturate links as the window can go up to 2MB
with default parameters.  Has this hit consumer devices yet?  This
could be bad it this rolls out before widespread use of AQM. ]

When a small amount of loss occurs, such as one or much less than the
current window size, TCP cuts the current window size in half and
retransmits the packet for the window in flight (ignoring selective
acknowledgment extension aka SACK for the moment).

If the buffer is way too small, then a large amount of premature drop
occurs when the buffer limit is hit.  Lots of TCP flows slow down.
The long RTT flows slow down the most.  Some retransmission occurs
(which doesn't help congestion).  If there is a long period of drop
relative to a short RTT, then a entire window can be dropped and this
is terrible for TCP (slow start is initiated after delay based on an
estimate of RTT and RTT stdev, or 3 sec if RTT estimate is stale -
this is a TCP stall).  So with too little buffer some TCP flows get
hammered and stall.  TCP flows with long RTT tend to stall less but
are more sensitve to the frequency of drop events and can get
extremely slow due to successively cutting window in half and then
growing the window linearly rather than exponentially.

With tiny buffers really bad things tend to happen.  The rate of
retransmission can drive goodput (the amount of non-retransmit traffic
per time) can drop substantially.  Long RTT flows can become
hopelessly slow.  Stalls become more common.  In the worst case (which
has been observed in a ISP network during a tiny buffer experiment
about a decade ago, details in private email) TCP synchronization can
occur, and utilization and goodput drop dramatically.

A moderate amount of buffer is good for all TCP.  A large buffer is
good for long RTT TCP flows, particularly those that have increased
max window.  As mentioned before, any but a very small buffer is bad
for interactive real time applications.

Enter AQM.  A large buffer can be used but with a lower target delay
and some form of AQM to introduce a low rate of isolated drops as
needed to slow the senders.  Avoiding queue tail drop events where a
lot of drops occur over an interval lowers the amount of
retransmission and avoids stalls.  Long RTT flows tend to get
penalized the most.

Fairness is not great with a single queue and AQM but this is much
better than a single queue with either small or large buffer and tail
drop.  Fairness is greatly improved with some form of FQ or SFQ.

Ideally with FQ each flow would get its own queue.  In practice this
is not the case but the situation is greatly improved.  A real time
flow, which is inherently rate limited, would see minimal delay and no
loss.  A short RTT flow would see a moderate increase in delay and a
low level of loss (ie: typically much less than 1%) enough to slow it
down enough to avoid congestion.  a long RTT flow would see a moderate
increase in delay and no loss if still running slower than the small
RTT flows.  This does wonders for fairness and provides the best
possible service for each service type.

In practice, some FQ or SFQ queues have a mix of real time, low RTT
TCP, and high RTT TCP.  If any such queue is taking a smaller share
than other queues, delay is low and loss is low or zero.  If such a
queue is taking more than its share, then the situation is similar to
the single queue case.  Less flows end up in such a queue.  Cascaded
queues have been proposed and in some cases (no longer existing) have
been implemented.  In a cascaded SFQ scheme, the queues taking more
than their share are further subdivied.  Repeat the subdivision a few
times and you can end up with the large bandwidth contributors in
their own queue and getting a fair share of capacity.

So excuse the length of this but solving bufferbloat is *not* a silver
bullet.  Not understanding that point and just making buffers really
small could result in an even worse situation than we have now.

Curtis

ps - Some aspects of this may not reflect WG direction.  IMHO- the
down sides of just making buffers smaller and/or setting low delay
targets may not be getting enough (or any) attention in the WG.  Maybe
discussion wouldn't hurt.

---

From: Daniel Havey <[email-masked]>
Date: Fri, 27 Feb 2015 19:09:37 +0000 (UTC)

Have to hop on a plane soon.  But yes and yes!  I think you are talking about the queue sizing problem as I like to call it instead of bufferbloat.  I have some work in that direction in my dissertation defense that I am about to give.

However, I also have an exigent problem.  In that same defense I will undoubtedly be asked, "Do you have evidence to prove that queue sizing is a significant problem?"

The fact is that I do not.  I have a train of logic that indicates the problem is significant, but, that is not the same as a study.  Isn't there something from cablelabs?

Eeeeeeerrrrrrrgggggghhhhhh!  I am glad I will only have to defend once in my lifetime.

...Daniel

________________________________
From: Curtis Villamizar <[email-masked]>
To: Daniel Havey <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Friday, February 27, 2015 10:52 AM
Subject: Re: [aqm] Is bufferbloat a real problem?

Daniel,

Curtis

---

From: Daniel Havey <[email-masked]>
Date: Fri, 27 Feb 2015 11:28:58 -0800

Switching to gmail because Yahoo is too horrible to use.

Like I said, I agree that bufferbloat is only 1 part of a two sided
problem.  The queue with respect to each flow can be either two large
or too small (and sometimes just right?).  Anyways, I'm just wondering
if there are any measurement studies out there that show the effects
of this problem in a formal way.

It might be an impossible problem.  What provider is going to want to
help publish data that shows they have poor queue sizing?  Anyways,
I'm looking for a way to demonstrate that this is a real problem in a
dissertation defense.  Perhaps when asked the question I should just
launch into a long explanation about how the queue can be too small or
too large or even both if there are multiple flows in the queue and
that solving the problem requires more than just shortening the queues
or using AQM to tune them to a particular RTT?  I dunno.

It would be nice if we had some measurement studies, but, that might
not be possible given the realities that we face on the Internet
today.

...Daniel

---

From: David Collier-Brown <[email-masked]>
Date: Fri, 27 Feb 2015 21:00:13 -0500

IMHO, removing latency is the aim of FQ. Once done, buffer sizes can be 
unbounded (save by price (;-))

--dave

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
[email-masked]           |                      -- Mark Twain

---

From: KK <[email-masked]>
Date: Fri, 27 Feb 2015 18:16:12 -0800

This could also be done by not having to depend on Œloss¹ as the primary
source of feedback...
-- 
K. K. Ramakrishnan
Professor
Dept. of Computer Science and Engineering
University of California, Riverside
Rm. 332, Winston Chung Hall
Tel: (951) 827-2480

Web Page: http://www.cs.ucr.edu/~kk/

On 2/27/15, 6:00 PM, "David Collier-Brown" <[email-masked]> wrote:

>> In message 
>><[email-masked]>
>> Daniel Havey writes:
>>   
>>>

---

From: David Collier-Brown <[email-masked]>
Date: Fri, 27 Feb 2015 21:45:19 -0500

Yup!

Loss is a bit of like hitting someone with  a 2 x 4" as a clue-stick. It 
hurts, but it sure does work!

--dave

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 28 Feb 2015 06:45:09 +0100 (CET)

On Fri, 27 Feb 2015, Daniel Havey wrote:

> problem.  The queue with respect to each flow can be either two large or 
> too small (and sometimes just right?).  Anyways, I'm just wondering if 
> there are any measurement studies out there that show the effects of 
> this problem in a formal way.

There are even videos showing this on youtube, where downloading at the 
same time as doing video conferencing means the video conferencing works a 
lot worse, and also that loading a web page takes a lot longer (due to DNS 
resolving packets, SYNs etc being stuck behind a lot of data packets).

https://www.youtube.com/watch?v=-D-cJNtKwuw for instance.

Jim Gettys and Dave Taht (and others) have done wonderful jobs in 
demonstrating that this is indeed a problem. I know gobs of users who know 
this is a problem as well, but they don't know how to fix it. People 
active in the bufferbloat movement have shown that there are solutions, 
and have shown these to work. There are papers and there are videos to 
show this. Even the RRUL test tool kit shows this very well if you 
understand what "500ms add latency" will mean to your Internet experience.

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 28 Feb 2015 20:34:44 -0500

In message <[email-masked]>
 
> unbounded (save by price (;-))

FQ and truly huge buffers and no AQM would also be seriously broken
and qualify as a bufferbloat problem.  Realtime would be OK if it were
rate limited by audio or video encoding.  A TCP flow would keep
filling its FQ buffer until RTT was absurdly large and other timers
kicked in.  Poor real time flow that had the bad luck to get stuck in
the same FQ queue as a long lived TCP flow.

FQ is also not a silver bullet but it is part of some good solutions,
perhaps the best solutions we know of at this point.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 28 Feb 2015 20:42:27 -0500

In message <[email-masked]>
KK writes:
 
> This could also be done by not having to depend on "loss" as the primary
> source of feedback...
>  
> -- 
> K. K. Ramakrishnan
> Professor

DECBit was a disaster.

Is there something else you had in mind?

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 28 Feb 2015 20:52:26 -0500

In message <[email-masked]>
 
> hurts, but it sure does work!

ECN might be a touch gentler.  But loss on the order of 10^-4 or less
doesn't hurt too bad.

With classsic TCP (ie: newreno or older and anything newer but not
hyper-aggresive) the estimates of the amount of loss per D*BW product
done by Matt Mathis still hold.  Now if I could just remember what
that estimate was ... in any case you get to extremely tiny loss with
anything over a few Mb/s and it goes up with square of D*BW.

Hyper-aggresive TCP (ie: CUBIC) need to be hit a lot harder.  This is
where FQ/SFQ really comes in handy.

Curtis