From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andy Furniss <adf.lists@gmail.com>
Date: Mon, 15 Feb 2016 22:43:53 +0000
Subject: Re: Query about tc configuration and associated network issues
Message-Id: <56C254A9.90802@gmail.com>
List-Id: <lartc.vger.kernel.org>
References: <20160215200607.Horde.Q4KQsnbmg5I5uPggYzCERU1@webmail.duth.gr>
In-Reply-To: <20160215200607.Horde.Q4KQsnbmg5I5uPggYzCERU1@webmail.duth.gr>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
To: lartc@vger.kernel.org

Δημήτριος Μάστορας wrote:
> Hello,
>
> I work on a master thesis project regarding broadband connection
> sharing. My network topology is as follows: 1. A PC which is
> connected to the Internet via eth0 and shares its connection with
> other computers via wlan0 (as a hotspot). 2. Two laptops serving as
> traffic generators connected to the hotspot through WiFi. 3. A PC
> serving as a traffic sink.
>
> I’m using the D-ITG traffic generator to emulate HTTP traffic. One of
>  the laptops runs ITGSend in multi-flow mode to generate
> simultaneously several flows(e.g. 100 flows) whose traffic is
> delivered to the sink (3) which runs ITGRecv.
>
> I have tested this scenario without having any tc rules [qdisc,
> class, filter] applied, and it works fine.
>
> The problem I'm facing is that when I am setting a bandwidth limit
> (downlink: 10Mbps, uplink:200Kbps) and testing different queueing
> configurations(for example HTB, prio) (see the attached file - SBS),
>  ITGRecv gives me an error and drops the connection.
>
> Given that without any tc rules applied my system works fine, I’m
> guessing that tc is affecting D-ITG somehow. After some researching I
>  wasn’t able to pin point what is the issue. For example, my initial
>  guess was the due to the limited bandwidth, lots of out of order
> packets were delivered to the sink, or IP fragmentation could be the
> issue, but I wasn't able to verify any of these assumptions through
> netstat –sa.
>
> Does anyone have any idea what the problem could be? Is anything
> wrong with my tc configuration? Is there any chance that a kernel
> configuration might solve the issue?

arp will go to htb default unless you filter elsewhere and yours is only
10kbit. I've never tested pfifo_fast with htb - maybe it doesn't help
arp, plus its length may depend on the txqlen of the $IF - maybe for
testing consistency it would be better to use queues that you choose the
length/behavior of and don't forget about arp.

With htb if no default is used, unclassified goes unshaped - which is
nice for arp.

HFSC is different, unclassified is dropped, so not so good if arp is
unclassified.

wondershaper was flawed because you have make sure child bandwidths add
up to parents.