We need a way to enable TCP Explicit Congestion Notification on RouterOS, so when eg TCP tunnels are established, we will get the increase in efficiency and reduction in packet loss. The current linux default is to accept ECN, but not request it when initiating connections.
Thus, we need a config option to do this:
echo 1 >/proc/sys/net/ipv4/tcp_ecn
A good candidate for RouterOS 7.
I’d rather say, a good candidate for ‘IP → Settings’ in RouterOS v6.12 =)
Indeed. With a significant number of competing TCP flows, Zheng and Kinicki demonstrate a 15% improvement in goodput (ie useful TCP segments, flow efficiency) through an ECN-capable router, page 15:
http://web.cs.wpi.edu/~rek/ISCC02talk.ppt
Anyway, let me know if anything more is needed to submit this as a feature request for RouterOS. Many thanks!
write to support@mikrotik.com for an answer
any chance to see update/implementation on-topic ?
even w/o say PURPLE queues ( f-GREEN and s-GREEN are not ECN-dependant) there was TOO much tech in modern networking that fail to work or Severely underperfrom w/o ECN support(both support, requence, enforcement, enabled/toggled in all kinds/points of gear/networks).
its rather “simple update” to ROS, not demanding newer kernel or newer code, just extra checkbox(like say “routing cache” enabling or one for “syncookie” or for “RP Filter”(if MT decide to implement all 3 options for)in option for ROS to be aware in bootime about dat option/switch to perform according to. so there was no need to wait for ROS7 or much manpower/hours of work needed i suppose.
for anyone new to topic:
https://en.wikipedia.org/wiki/Explicit_Congestion_Notification
https://tools.ietf.org/html/rfc3168
as basic introduction.
same about “enabling/disabling timestamps” - sometimes they Should be disabled, sometimes they are Lifesavers so there was “always should option about” such things in general.
Any news about ECN support ?
It would be more interesting to know (as these are routers) which queue types, if any, support ECN
in MikroTik products.
Any news on ECN topic?
Being able to set the ECN flag is a much different thing than knowing whether or not a queuing mechanism supports setting and receiving the ECN flag inherently. Just being able to set the flag on an outbound packet doesn’t mean that a router “supports ECN.” True ECN support would mean the queuing mechanism would slow the transmission of data when it observed a packet with the ECN flag set, rather than dropping packets.
should it not be the other way around ,that the queing mechanism detects that the queue is full, sets the ECN flag, the receiver bounces the ECN flag back to the sender ,and the sender lowers the transmission rate?
That is right, ECN router support requires some form of queuing where it would be applied (i.e. queue overflows detected and ECN bits adjusted) plus there has to be support in TCP but that would normally not be in the router itself, but in the endpoint.
Exception is only when the router is the TCP endpoint, e.g. in a TCP-based VPN. But enabling only the TCP part of it will still not bring much in most scenarios (where the bandwidth bottleneck is the internet connection next to the router).
+1 for ECN support and BBR congestion control
please implement them mikrotik
BBR is for clients and servers, a router doesn’t care.