Re: [Bloat] [Codel] Network test tools for many parallel/concurrent connections?

[Rick Jones]

It will not match what one can get from tcptrace, or commercial 
solutions, but netperf can be asked to emit a number of potentially 
"intersting" things.  Using the "omni output selectors" one can request 
statistics for some interesting latencies:


raj@tardy:~$ netperf -- -O ? | grep LAT
RT_LATENCY
MIN_LATENCY
MAX_LATENCY
P50_LATENCY
P90_LATENCY
P99_LATENCY
MEAN_LATENCY
STDDEV_LATENCY

For a STREAM test those will be based on time in the send call.  For a 
MAERTS test those will be time in the receive call.  For an RR test 
those will be the round-trip times at the application layer.


You can also ./configure --enable-histogram and if the verbosity is set 
to 2 or more, a histogram of the distribution will be emitted which will 
resemble:


Histogram of time spent in send() call.
UNIT_USEC :0:0:  434: 404912: 715323: 800663: 263305: 9336: 
2439: 1522

TEN_USEC  :0: 2276:   41:   48:   97:   67:   79:   17:5:7
HUNDRED_USEC  :0:   28:2:2:0:2:0:0:1:1
UNIT_MSEC :0:3:2:0:1:0:1:0:0:0
TEN_MSEC  :0:0:0:0:0:0:0:0:0:0
HUNDRED_MSEC  :0:0:0:0:0:0:0:0:0:0
UNIT_SEC  :0:0:0:0:0:0:0:0:0:0
TEN_SEC   :0:0:0:0:0:0:0:0:0:0
>100_SECS: 0
HIST_TOTAL:  2200614

when running under Linux, netperf also knows how to report the number of 
TCP retransmissions encountered over the life of the data connection:


raj@tardy:~$ netperf -- -O ? | grep -i retran
LOCAL_TRANSPORT_RETRANS
REMOTE_TRANSPORT_RETRANS

And if you want to have an idea of what each individual netperf was 
doing in terms of mbit/s or trans/s over discrete points in its 
lifetime, you can ./configure --enable-demo and it will emit interim 
results at roughly the requested interval which can then be 
post-processed.  An example of that being done can be found in 
doc/examples/runemomniaggdemo.sh script and doc/examples/post_proc.py


happy benchmarking,

rick jones
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Network test tools for many parallel/concurrent connections?

[Jesper Dangaard Brouer]

On Tue, 14 May 2013 09:28:54 -0700
Isaac Konikoff  wrote:

> Candela makes a Linux based network traffic test tool called 
> LANforge-FIRE. It can generate in excess of 50,000 TCP connections
> among other features. It is a proprietary tool, but we'll send out
> free licenses to students and those working on non-commercial open
> source projects.

I guess Red Hat does not qualify as a non-commercial open source
project ;-)

This actually sounds interesting.  I'll try an talk to my manager to
find some budget for this purpose (lets pick this up offlist).

-- 
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
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Codel] Network test tools for many parallel/concurrent connections?

[Jesper Dangaard Brouer]

On Tue, 14 May 2013 07:46:02 -0700
Dave Taht  wrote:

> I still use tcptrace and xplot.org for deep dives.

Okay, I just hoped something new popped up.

Didn't we add some tcp trace system to the kernel?


> I just fired off 2048 netperfs to localhost on my laptop.  It started
> bogging down at 1000 but made it to the end, all connections chugging
> away.

So you just did a for loop with netperf's I assume.
If so, remember to adjust the "ulimit" of the shell.
Run 'ulimit -a' and you most likely need to adjust "ulimit -u".

I also played with "iperf --parallel" but iperf is not consistently
starting all the TCP connections.


> Probably a better tool would be the apache benchmark `ab` or
> something else that is built to stress out web sites.

Yes, I guess that might be the easiest "quick" solution.

-- 
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
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Network test tools for many parallel/concurrent connections?

[Jesper Dangaard Brouer]

On Tue, 14 May 2013 08:47:26 -0700
Stephen Hemminger  wrote:

> You may want to look at some of the "realistic" load tools since
> in real life not all flows are 100% of bandwidth and long lived.

Well perhaps it would be easier to use some apache load test tool, but
in this test scenario I just want see how well fq_codel scales with
many concurrent bulk transfers.

Can people on the list recommend any commercial test-equip solutions?

-- 
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
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[Bloat] [Packet Video 2013] Submission deadline in 4 weeks

[Pål Halvorsen]

Packet Video 2013
Sponsored by IEEE Communications Society
December 12 and 13th
San Jose, CA USA
-

Call for Papers

The 20th International Packet Video Workshop (PV 2013) is devoted
to presenting technological advancements and innovations in video
and multimedia transmission over packet networks, in particular
wireless and Internet networks. The workshop provides a unique
venue for people from the media coding and networking fields to
meet, interact and exchange ideas. Its charter is to promote the
research and development in both established and emerging areas of
video streaming and multimedia networking. PV 2013 will be held in
San Jose, CA USA on December 12 and 13th. As in previous years, the
workshop will be a single-track event and welcomes paper submissions
from both cutting-edge research, and business and consumer
applications.



PV 2013 will be immediately following the Picture Coding Symposium,
which will be held also in San Jose, CA.


There will be both regular and special sessions. In general, the
workshop seeks papers in all areas of media delivery over packet-based
networks. Authors are especially encouraged to submit papers with real-
world experimental results and real datasets. Topics of interest include
(but are not limited to):
- Cloud and peer-to-peer system architectures
- Media streaming, distribution and storage support
- Multimedia communications and system security
- Multi-core and many-core architecture support
- Networked GPUs, graphics and virtual environments
- Networked games, real-time immersive systems
- Operating system, middleware and network support
- Web 2.0 systems and social networks
- Next-generation video like multi-view, panorama and 3D
- Wireless networks and embedded systems for multimedia applications
- Content-centric networking

In particular, we are interested in soliciting papers that discuss
system-level support improving performance with multi-core and many-core
processors, as well as papers that focus on multimedia applications on
mobile devices and/or in a cloud-computing environment.


Prospective authors are invited to submit an electronic version of full
papers, in PDF format, up to 8 printed pages in length (double column
IEEE conference format). The proceedings will be published by the IEEE
Xplore shortly after the workshop.


For the Technical Program Committee and details regarding special sessions,
refer to the PV 2013 Web site at http://pv2013.itec.aau.at/.

ORGANIZATION

General Co-Chairs
Ali C. Begen, Cisco (Canada)
Bernd Girod, Stanford Univ.

Technical Program Co-Chairs
John Apostolopoulos, Cisco (USA)
Pål Halvorsen, University of Oslo

Publicity Chair
Christian Timmerer, AAU Klagenfurt

Publications Chair
Zhi Li, Cisco (USA)

Steering Committee
Chang Wen Chen, SUNY Buffalo, USA
Tsuhan Chen, Cornell, USA
Reha Civanlar, Ozyegin Univ., Turkey
Pascal Frossard, EPFL, Switzerland
Bernd Girod, Stanford Univ., USA
Jin Li, Microsoft, USA
Fernando Pereira, IST-IT, Portugal
Amy Reibman, AT&T, USA
Mihaela van der Schaar, UCLA, USA
Ralf Schaefer, HHI, Germany
Eckehard Steinbach, TUM, Germany
Ming-Ting Sun, Univ. of Wash., USA

Important Dates
All Papers due: June 10th 
Acceptance Notifications: Sept. 13th 
Camera-ready: Oct. 18th

Further Information
http://pv2013.itec.aau.at/

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Network test tools for many parallel/concurrent connections?

[Jim Gettys]

There are really three kinds of killer traffic here, and it's important to
understand the differences so as to best design testing:

   1) long lived flows that clobber you and ruin your whole day.

   2) "streaming" video traffic (e.g. netflix, youtube, hulu), that are
actually "chunking" data over TCP, and putting periodic latency into your
connection as they temporarily build some queue.

fq_codel can deal really, really well with both 1 and 2.  But the number of
flows is usually not very large.

   3) the DOS attacks of visiting a new sharded web page on your
broadband/wireless connection, where you get the multiplication of N
connections * TCP Initial Window size, sometime resulting in pulses of
order hundred packets in a ton of new flows.  I've measured transient
latency of order 100's of milliseconds on a 50Mbps cable system! These web
sites generate a bunch of flows effectively simultaneously, each with often
only a few packets so never even do slow start to speak of.

Exactly what damage is done given 3, using fq_codel's algorithm isn't
entirely clear to me.  Many/most images on such sharded web sites are quite
small, even less than one packet at times.

fq_codel is clearly radically better than nothing at handling 3, but I
suspect we still have work to do...  Spdy will help if/when fully deployed,
but the ability to game buffers remains, and will continue to provide
incentive to anti-social applications to mis-behave.  We're really far from
done, but as Matt Mathis notes, what we have now in fq_codel is s,
so much better than the current disaster, we shouldn't wait to deploy
something 'better' while working out problems like that.

I've thought for a while that exactly how we want to define a "flow" may
depend on where we are in the network: what's appropriate for an ISP is
different than what we do in the home, for example.

How best to test for the problems these generate, at various points in the
network, is still a somewhat open question.  And ensuring everything works
well at scale is extremely important.

I'm glad Jesper is doing scaling tests!
- Jim



On Tue, May 14, 2013 at 1:01 PM, Dave Taht  wrote:

>
> On May 14, 2013 12:21 PM, "Stephen Hemminger" 
> wrote:
> >
> > On Tue, 14 May 2013 15:48:38 +0200
> > Jesper Dangaard Brouer  wrote:
> >
> > >
> > > (I'm testing fq_codel and codel)
> > >
> > > I need a test tool that can start many TCP streams (>1024).
> > > During/after the testrun I want to know if the connections got a fair
> > > share of the bandwidth.
> > >
> > > Can anyone recomment tools for this?
> > >
> > > After the test I would also like to, "deep-dive" analyse one of the TCP
> > > streams to see how the congestion window, outstanding-win/data is
> > > behaving.  Back in 2005 I used-to-use a tool  called
> > > "tcptrace" (http://www.tcptrace.org).
> > > Have any better tools surfaced?
> > >
> >
> >
> > You may want to look at some of the "realistic" load tools since
> > in real life not all flows are 100% of bandwidth and long lived.
>
> You may want to look at some realistic load tools since in real life
> 99.9Xx% of all flows are 100% of bandwidth AND long lived.
>
> At various small timescales a flow or flows can be 100% of bandwidth.
>
> But it still takes one full rate flow to mess up your whole day.
>
> This is why I suggested ab.
>
> Here bandwidth is an average usually taken over a second and often much
> more. If you sample at a higher resolution, like a ms, you are either at
> capacity or empty.
>
> Another way of thinking about it is for example, mrtg takes samples every
> 30 seconds and the most detailed presentation of that data it gives you is
> on a 5 minute interval. The biggest fq codel site I have almost never shows
> a 5 minute average over 60% of capacity, but I know full well that Netflix
> users are clobbering things on a 10 sec interval and that there are
> frequent peaks where it is running at capacity for a few seconds at a time
> from looking at the data on a much finer interval and the fq codel drop
> statistics.
>
> > ___
> > 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
>
> 
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Network test tools for many parallel/concurrent connections?

[Dave Taht]

On May 14, 2013 12:21 PM, "Stephen Hemminger" 
wrote:
>
> On Tue, 14 May 2013 15:48:38 +0200
> Jesper Dangaard Brouer  wrote:
>
> >
> > (I'm testing fq_codel and codel)
> >
> > I need a test tool that can start many TCP streams (>1024).
> > During/after the testrun I want to know if the connections got a fair
> > share of the bandwidth.
> >
> > Can anyone recomment tools for this?
> >
> > After the test I would also like to, "deep-dive" analyse one of the TCP
> > streams to see how the congestion window, outstanding-win/data is
> > behaving.  Back in 2005 I used-to-use a tool  called
> > "tcptrace" (http://www.tcptrace.org).
> > Have any better tools surfaced?
> >
>
>
> You may want to look at some of the "realistic" load tools since
> in real life not all flows are 100% of bandwidth and long lived.

You may want to look at some realistic load tools since in real life
99.9Xx% of all flows are 100% of bandwidth AND long lived.

At various small timescales a flow or flows can be 100% of bandwidth.

But it still takes one full rate flow to mess up your whole day.

This is why I suggested ab.

Here bandwidth is an average usually taken over a second and often much
more. If you sample at a higher resolution, like a ms, you are either at
capacity or empty.

Another way of thinking about it is for example, mrtg takes samples every
30 seconds and the most detailed presentation of that data it gives you is
on a 5 minute interval. The biggest fq codel site I have almost never shows
a 5 minute average over 60% of capacity, but I know full well that Netflix
users are clobbering things on a 10 sec interval and that there are
frequent peaks where it is running at capacity for a few seconds at a time
from looking at the data on a much finer interval and the fq codel drop
statistics.

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

Re: [Bloat] Network test tools for many parallel/concurrent connections?

[Isaac Konikoff]

Candela makes a Linux based network traffic test tool called 
LANforge-FIRE. It can generate in excess of 50,000 TCP connections among 
other features. It is a proprietary tool, but we'll send out free 
licenses to students and those working on non-commercial open source 
projects.


Thanks,
Isaac



On 05/14/2013 07:46 AM, Dave Taht wrote:

I still use tcptrace and xplot.org  for deep dives.

I just fired off 2048 netperfs to localhost on my laptop.  It started
bogging down at 1000 but made it to the end, all connections chugging away.

Probably a better tool would be the apache benchmark `ab` or something
else that is built to stress out web sites.

On May 14, 2013 10:15 AM, "Jesper Dangaard Brouer" mailto:jbro...@redhat.com>> wrote:


(I'm testing fq_codel and codel)

I need a test tool that can start many TCP streams (>1024).
During/after the testrun I want to know if the connections got a fair
share of the bandwidth.

Can anyone recomment tools for this?

After the test I would also like to, "deep-dive" analyse one of the TCP
streams to see how the congestion window, outstanding-win/data is
behaving.  Back in 2005 I used-to-use a tool  called
"tcptrace" (http://www.tcptrace.org).
Have any better tools surfaced?

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




--
Isaac Konikoff
Candela Technologies
konik...@candelatech.com
Office: +1 360 380 1618
Cell: +1 360 389 2453
Fax: +1 360 380 1431
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Network test tools for many parallel/concurrent connections?

[Stephen Hemminger]

On Tue, 14 May 2013 15:48:38 +0200
Jesper Dangaard Brouer  wrote:

> 
> (I'm testing fq_codel and codel)
> 
> I need a test tool that can start many TCP streams (>1024).
> During/after the testrun I want to know if the connections got a fair
> share of the bandwidth.
> 
> Can anyone recomment tools for this?
> 
> After the test I would also like to, "deep-dive" analyse one of the TCP
> streams to see how the congestion window, outstanding-win/data is
> behaving.  Back in 2005 I used-to-use a tool  called
> "tcptrace" (http://www.tcptrace.org).
> Have any better tools surfaced?
> 


You may want to look at some of the "realistic" load tools since
in real life not all flows are 100% of bandwidth and long lived.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Network test tools for many parallel/concurrent connections?

[Dave Taht]

I still use tcptrace and xplot.org for deep dives.

I just fired off 2048 netperfs to localhost on my laptop.  It started
bogging down at 1000 but made it to the end, all connections chugging away.

Probably a better tool would be the apache benchmark `ab` or something else
that is built to stress out web sites.
On May 14, 2013 10:15 AM, "Jesper Dangaard Brouer" 
wrote:

>
> (I'm testing fq_codel and codel)
>
> I need a test tool that can start many TCP streams (>1024).
> During/after the testrun I want to know if the connections got a fair
> share of the bandwidth.
>
> Can anyone recomment tools for this?
>
> After the test I would also like to, "deep-dive" analyse one of the TCP
> streams to see how the congestion window, outstanding-win/data is
> behaving.  Back in 2005 I used-to-use a tool  called
> "tcptrace" (http://www.tcptrace.org).
> Have any better tools surfaced?
>
> --
> 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
> ___
> 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

[Bloat] Network test tools for many parallel/concurrent connections?

[Jesper Dangaard Brouer]

(I'm testing fq_codel and codel)

I need a test tool that can start many TCP streams (>1024).
During/after the testrun I want to know if the connections got a fair
share of the bandwidth.

Can anyone recomment tools for this?

After the test I would also like to, "deep-dive" analyse one of the TCP
streams to see how the congestion window, outstanding-win/data is
behaving.  Back in 2005 I used-to-use a tool  called
"tcptrace" (http://www.tcptrace.org).
Have any better tools surfaced?

-- 
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
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Codel] Latest codel, fq_codel, and pie sim study from cablelabs now available

[Eric Dumazet]

On Tue, 2013-05-14 at 03:24 -0700, Dave Taht wrote:

> 
> As for dealing with incoming vs outgoing traffic, it might be possible
> to use connection tracking to successfully re-mark traffic on incoming
> to match the outgoing. 

Indeed, we had a discussion about that during Netfilter workshop 2013 in
Copenhagen.

(ability to use conntracking from ingress tc filter)



___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Codel] Latest codel, fq_codel, and pie sim study from cablelabs now available

[Jesper Dangaard Brouer]

On Mon, 13 May 2013 22:26:04 -0400
Dan Siemon  wrote:

> On Thu, 2013-05-02 at 15:04 +0300, Jonathan Morton wrote:
> > I can easily see a four-tier system working for most consumers, just
> > so long as the traffic for each tier can be identified - each tier
> > would have it's own fq_codel queue:

I generally like it, but some notes below.

> > 1) Network control traffic, eg. DNS, ICMP, even SYNs and pure ACKs -
> > max 1/16th bandwidth, top priority

I used a separate queue for ACK packets, and directly calculated the
needed bandwidth for ACK packets based on the downstream link.
See:
 
http://sourceforge.net/p/adsl-optimizer/code/HEAD/tree/trunk/kode/optimizer/queues/include/functions.inc#l94

(My future idea was to implement an ACK aware qdisc, that would drop
accumulative ACK packets or delay ACKs to influence downstream behavior)

> > 2) Latency-sensitive unresponsive flows, eg. VoIP and gaming - max
> > 1/4 bandwidth, high priority
> > 
> > 3) Ordinary bulk traffic, eg. web browsing, email, general purpose
> > protocols - no bandwidth limit, normal priority

So, these two above is "known-good" traffic, that gets categorized into
these.

> > 4) Background traffic, eg. BitTorrent - no bandwidth limit, low
> > priority, voluntarily marked, competes at 1:4 with normal.

I worked with two classes for this, (1) a default fall-through traffic
class, where uncategorized traffic end-up. (2) a known "bad" low-prio
traffic class, for traffic I could categorize as BitTorrent etc.

http://sourceforge.net/p/adsl-optimizer/code/HEAD/tree/trunk/kode/optimizer/queues/htb/optimizer_htb.sh#l227


> The above is close to what I implemented:
> http://git.coverfire.com/?p=linux-qos-scripts.git;a=blob;f=src-3tos.sh;h=3e88c2fa5f2feb0163c052086541ba17579a3c37;hb=HEAD

Nice, and thank you for mentioning my (old) site: http://www.adsl-optimizer.dk

And actually have a script that mentions (and can use) the ADSL
linklayer options :-)


> The above aims for per-host fairness and three tiers per host. Each
> tier has an fq_codel QDisc (configurable).
> 
> Some performance results can be found at:
> http://www.coverfire.com/archives/2013/01/01/improving-my-home-internet-performance/

p.s. I love your "ping-exp" tool and the nice graphs it generates!

Others go clone:
 git clone http://git.coverfire.com/ping-exp.git


-- 
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
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Codel] Latest codel, fq_codel, and pie sim study from cablelabs now available

[Dave Taht]

On Mon, May 13, 2013 at 9:56 PM, Tristan Seligmann
wrote:

> On Tue, May 14, 2013 at 4:26 AM, Dan Siemon  wrote:
>
>> It's pretty easy to configure the Transmission Bittorrent client to mark
>> packets.
>>
>
It is not clear to me that transmission correctly marks uTP traffic,
particularly on IPv6. grep the current sources for "TCLASS"?


>
>  Unfortunately this only helps with outgoing traffic. Marking on inbound
> traffic is at the mercy of the torrent peer and your ISP (in my case, my
> ISP seems to overwrite the TOS/DS field indiscriminately, not that you
> would want to trust the marking for inbound traffic anyway), and matching
> by port is also not feasible as outgoing connections involve a random port
> on my side, and an arbitrary port on the peer's side.
>

It is very evident that incoming traffic needs to be re-marked at the
gateway, as a huge percentage of traffic I see at one of my sites is marked
background that shouldn't be. (or there's a bug in my script)

Inappropriately marking traffic as background has side effects on stuff
inside the gateway, particularly on wifi, as it gets tossed into the hw
background queue, which has different scheduling characteristics than best
effort.

As for dealing with incoming vs outgoing traffic, it might be possible to
use connection tracking to successfully re-mark traffic on incoming to
match the outgoing.



> --
> mithrandi, i Ainil en-Balandor, a faer Ambar
>
> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>


-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat