0

Is the ECN marking in the IP header is performed by default in Ubuntu (4.15.x kernel) or should the kernel be recompiled with a special option? I configured a RED ingress queue at an Ubuntu machine, net.ipv4.tcp_ecn is set to 1 in all hosts of the network and ECN is enabled in the tc qdisc command.

I am using 4 ubuntu machines using this topology: client --- rt1 --- rt2 --- server.
iperf -s is running at the server side and iperf -c server -P 100 -d at the client side.
(client --- rt1): 100mbit 1 ms latency; (rt1 --- rt2): 10mbit 1ms latency; (rt2 --- server): 100mbit 1ms latency;

The RED queue is configured at the client-facing interface of rt1 as following:

Create ingress on external interface

tc qdisc add dev $ext handle ffff: ingress

ifconfig $ext_ingress up

Forward all ingress traffic to the IFB device

tc filter add dev $ext parent ffff: protocol all u32 match u32 0 0 action mirred egress redirect dev $ext_ingress

Apply RED on the IFB device

tc qdisc add dev $ext_ingress root red limit 50000 min 4167 max 12500 burst 7 avpkt 1000 probability 0.5 bandwidth 100mbit ecn

I see dropped packets as early drop due to congestion but there are no marked packets.

v1mm3r
  • 1
  • 2
  • With the 10mbit between rt1-rt2 (and so between client and server), will there ever be packets that need marking? – Gerard H. Pille May 11 '20 at 07:51
  • The link between the client and rt1 is 100mbit. I am afraid that the average queue exceeds the maximum threshold most of the times, therefore the RED queue degenerates into a simple Tail Drop queue. I think I might check the RED parameters. It's very confusing though. – v1mm3r May 11 '20 at 09:42
  • RED is handling rt1 -> client (root option). Since packets arriving on rt1 from rt2 destined for the client, come in at max 10mbit, how could they ever exceed their queue? – Gerard H. Pille May 11 '20 at 10:46
  • Question updated! – v1mm3r May 11 '20 at 12:23
  • I wonder why, with iperf3, you can specify the congestion control algorithm ("-C" option). – Gerard H. Pille May 11 '20 at 12:35
  • I need to use RED queuing discipline in order to compare it with another system/framework that uses TCP Reno Congestion control with combined with RED. It's weird that ECN marking is done when I use fq_codel. It should definitely be related with some RED parameters. – v1mm3r May 11 '20 at 13:29
  • ECN is turned on by default with fq_codel. It wouldn't be that the order of the parameters is important? tc qdisc ... red limit bytes [ min bytes ] [ max bytes ] avpkt bytes [ burst packets ] [ ecn ] [ harddrop] [ bandwidth rate ] [ probability chance ] [ adaptive ] Grasping at straws here. – Gerard H. Pille May 11 '20 at 13:49
  • Perhaps try iperf3? ECN will only be used with "packets which indicate that their hosts honor ECN". Can that be verified in the packets you receive? – Gerard H. Pille May 11 '20 at 13:53
  • Tried the parameter order and iperf3 but still the same. tcp_ecn sys variable is set to 1 everywhere in the network. I can see from the .pcap file that the TCP-ECN-Echo Flag is set during the 3-way-hanshake and the packets have ip.dsfield.ecn set to 10 as ECN-Capable hosts, but the CE bit in the IP header is never set, even though I have overlimits dropped packets from ```tc -s -d qdisc``` – v1mm3r May 11 '20 at 22:13
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/107903/discussion-between-kr1stj0n-and-gerard-h-pille). – v1mm3r May 12 '20 at 01:48

1 Answers1

0

You should verify your kernel configuration for:

IP_NF_TARGET_ECN
NETFILTER_XT_MATCH_ECN

Perhaps with the Ubuntu kernel, it's just an extra module that needs to be loaded.

Gerard H. Pille
  • 2,569
  • 1
  • 13
  • 11
  • These options are compiled as modules. I loaded ```modprobe ipt_ECN``` and ```modprobe xt_ecn``` but didn't change anything. – v1mm3r May 10 '20 at 20:31