RED + ECN

v13 · Fri Dec 18, 2009 1:19 pm

Hello,

I'm doing some tests regarding ECN and I'm using RED queues on a Routerboard with Mikrotik v4.3. However, something doesn't work as expected and I'd like to know whether 'ecn' is used for RED queues.

For linux, when the 'tc' tool is used, one must add the 'ecn' keyword to allow for marking instead of dropping. For example, you must write:

tc qdiscc add root dev eth0 limit XX min XX max XX avpkt XX burst XX probability XX ecn

Note the 'ecn' keyword at the end.

The basic form of the test is done by having two machines, one at home behind the routerboard and one at a remote location over the Internet, that both use ECN for TCP and they succeed in negotiating ECN usage.

My current tests showed very similar results with and without using ECN, which is an indication of packets not being marked. This is somehow confirmed because there are no received packets with the ECE codepoint set (both ECN bits become 1). This codepoint is the indication of a marked packet.

So, can someone clarify whether 'ecn' is actually used or not in RED queues?

Apart from that, I've some suggestions for RED queues regarding winbox/interface:

Clarify what 'packet' means. Is RED somehow implemented in packet-mode or they are sizes just multiplied by avpkt?
Allow user to change the maximum mark/drop probability. What is the current value anyway?
Provide an easier/novice (for users) interface: Ask for "Maximum delay" in milliseconds, "Average packet size (1000 is a good default), Link bandwidth. Then ask for minimum and maximum thresholds as a percentage of the queue size limit. Limit is Delay * Bandwidth / (8 * 1000). Min is min_percentage * Limit. Max is max_percentage * Limit. Burst (in packets) can be either user-defined or set to (Min+Min+Max / (3*Avpkt)) just like tc recommends.

If you need any help regarding ECN/RED please contact me (I'm currently doing a related PhD). I'd be glad to help in improving ECN+RED experience with mikrotik.

p.s. RED stands for "Random Early Detection" but it is mentioned as "Random Early Drop" in at least one wiki page.

Chupaka · Fri Dec 18, 2009 11:41 pm

http://wiki.mikrotik.com/wiki/Queue#RED

p.s. yes, it was 'RE Detection' in old manuals =) http://www.mikrotik.com/testdocs/ros/2.9/root/queue.php

v13 · Sat Dec 19, 2009 12:23 am

http://wiki.mikrotik.com/wiki/Queue#RED

Yes, that's the page where it is referred to as "Drop".

( I assume your answer had to do with the "Drop" / "Detection" thing and not with the questions )

Chupaka · Sat Dec 19, 2009 12:38 am

actually, that link was about questions =) what do you mean by 'mark'? manual says, there are only drops =)

v13 · Sat Dec 19, 2009 1:55 am

actually, that link was about questions =) what do you mean by 'mark'? manual says, there are only drops =)

First of all, RED is commonly used with ECN. When ECN is used, the router can mark packets instead of dropping them. Not supporting ECN with RED is a great loss. Supporting ECN with RED under Linux only requires a flag to be set. Everything else is performed by the kernel.

Apart from that, the page states:

When the average queue size reaches red-min-threshold, RED starts to drop packets randomly with linearly increasing probability as the average queue size grows up until the average queue size reaches the red-max-threshold

but it doesn't specify what is the maximum dropping probability.

RED has three queue-size related values: min, max and limit. When average queue size is less that min then there are no drops/marks. If average queue size is between min and max, then the drop probability of a packet is X*(avg_queue_size-min)/(max-min). If average queue size is >=max, then the drop probability is constantly X. The value of X is a parameter which (for mikrotik) is not possible to be altered and it is not mentioned at all. What is the default value of X? (There is also "burst", but you get the point) (X is called "the maximum mark/drop probability").

Finally, why does the interface ask the user to enter values as packets instead of bytes? RED has two modes (in theory): packet-mode and byte-mode. Latest research shows that byte mode is unfair and packet mode is suggested. Is mikrotik somehow implementing packet-mode for RED? AFAIK Linux only supports byte mode. If not, then how are the packet values converted to bytes? Simply by multiplying them with the value of avgpkt?

Chupaka · Sat Dec 19, 2009 2:54 am

When the average queue size reaches red-min-threshold, RED starts to drop packets randomly with linearly increasing probability as the average queue size grows up until the average queue size reaches the red-max-threshold

but it doesn't specify what is the maximum dropping probability.

If average queue size is >=max, then the drop probability is constantly X. The value of X is a parameter which (for mikrotik) is not possible to be altered and it is not mentioned at all. What is the default value of X? (There is also "burst", but you get the point) (X is called "the maximum mark/drop probability").

from the Manual:

all further packets are dropped

i.e. X = 1

p.s. how wide is ECN supported in current user OSes?..
p.p.s. and yes - ECN would be nice feature in ROS =)

v13 · Sat Dec 19, 2009 3:28 am

from the Manual:
all further packets are dropped
i.e. X = 1

Oh! You're right!

p.s. how wide is ECN supported in current user OSes?..

I understand you're referring to TCP's support for ECN and not for IP's support:
Linux supports it for a long time now. Initially it was enabled by default but now it seems to be disabled by default. AFAIK Vista support it but have it disabled by default. In general, noone knows if ECN is ever going to be used in large-scale.

p.p.s. and yes - ECN would be nice feature in ROS =)

... not to mention that it should be quite simple. (tc does it with just an extra parameter).

Chupaka · Sun Dec 20, 2009 11:47 am

well, in the light of disabling of ECN by default it doesn't look so attractive...

so, with ECN disabled, your RED + ECN will do nothing...

v13 · Sun Dec 20, 2009 1:33 pm

well, in the light of disabling of ECN by default it doesn't look so attractive...

so, with ECN disabled, your RED + ECN will do nothing...

The "default" is a matter of another kernel version. Currently it is disabled because there were some broken systems and firewalls that dropped packets with ECN (I have access to a network-camera that has this problem). However this seem to have changed a lot during the last years: I'm using ECN by default and haven't encountered problems for a long-time now.

There is also a "problem" regarding the ECN marks that were introduced in RFC3168. This is 8 years old but AFAIK some implementations still handle ECN the old-way, where there was an "ECT" and an "ECE" flag instead of having three codepoings (ECT(0), ECT(1), ECE).

Long-story-short, it would be nice if there was a way to enable ECN for RED queues in Mikrotik, without making this the default. Cisco routers already support that for WRED the proper way:
http://www.cisco.com/en/US/docs/ios/12_ ... rdecn.html
in a similar way with linux: By using "random-detect ecn" instead of just "random-detect".

RED + ECN

RED + ECN

Re: RED + ECN

Re: RED + ECN

Re: RED + ECN

Re: RED + ECN

Re: RED + ECN

Re: RED + ECN

Re: RED + ECN

Re: RED + ECN

Who is online