Analyzing fairness across multiple tcp flows in a packet capture?

[Dave Taht]

As a result of Byte queue limits actually giving the packet scheduler
layer something to do, at least on ethernet, I've given up on wireless
for a while.

I've been fiddling with QFQ (the quick fair scheduler) and Red,
to get a feel for how the results 'look', mostly in tcptrace + xplot.

I dumped the latest wip on that up on github before I dared boot
into a BQL enabled kernel...

https://github.com/dtaht/deBloat/tree/master/wip

(eqfq and various forms of eqfq.red are what I'm mostly fiddling with
- most of the
other scripts are garbage which I'll clean up in a bit)

You'd need a debloat-testing or bql enabled kernel and the latest iproute2 code
to mess with QFQ.

The good news is that a home router CAN run the above scripts -
and does run at well over 100Mbit with them over ethernet.

While in my limited testing QFQ feels like a win at these timescales
 and traffic volumes... reducing interstream latency to less than 2ms
 for the first new stream, as one example - I'd like to be doing something
comprehensive, not-ad-hoc, and repeatable by others.

it's really, really hard to 'see' what's really going on, in
particular measuring how well
flows are interleaved... So I'm curious if there is any tool out there that can
take a packet capture and determine that? (WFI (worst case fair index))

Adding netperf's tcp_rr test to the list seems like a good idea...

I did things like google for things like

"measuring fairness across flows" - which actually was quite
interesting, this paper
was kind of encouraging re the wireless mesh problem.

( http://www.ecsl.cs.sunysb.edu/tr/TR210.pdf )

but I digress. At the moment I'm fiddling with ethernet.

and poked through wireshark's plugins, but otherwise came up empty.

Alright, alright, enough on wired (I'm happy about wired at the moment)

Wireless, not so much.

I had meant to mention this wireless paper weeks ago:

www-users.aston.ac.uk/~pengx1/QoS-project/ants-08.pdf

It shows how EDCA (802.11e) works on 'g', and suggests an
interesting wireshark filter for analyzing real behavior on the
air, and the ironic money quote, for me, was...

"Fig. 5 demonstrates the effect of introducing 3 TCP streams
using legacy DCF at t = 30 and t = 60 seconds, respectively.
We can clearly see that the lack of service differentiation
results in the individual stations sharing the available
bandwidth equally"

I'm figuring the results of that wireshark filter will be
'interesting' on wireless-n as presently implemented. tcp's RTT
differences does interesting things...

-- 
Dave Täht
http://www.bufferbloat.net