RED 10 Throughput Unusable

@Bob:
That's true - he didn't mention the DoS Protection...I was once again typing faster than thinking [:D]

@Astaronator:
I  had yesterday little time to play around with one of my RED10 between Office (75/7,5 MBit Cable Line / default MTU 1500), and my UTM 9.2 Beta (9.171) on a 100/10 MBit Cable Line - also default MTU1500.

As UTM9.2 contains fixes and optimizations for the RED anyway (I love the new compression feature ;o)), I'm not sure, that the 9.1 Release behaves same. 

However I did tests with:
- lowered the MTU of the WAN Interface of the Router in front of the RED down to 1350 but UTM still with 1500
- lowered MTU of the WAN Interface of the UTM down to 1350 but Router in front of the RED with 1500
- tested both above with TCP Window Scaling enabled and disabled
- tested with global ICMP settings all off / all on 
- Tested with QoS on the UTM WAN Interface with Auto Tuning Options on and off

And interestingly the RED seems (at least with the used 9.2 beta) to behave extremely constant - independent of all the settings I changed. I tested the speed by copying a large .mkv movie from my NAS@home to the Office client behind the RED and always got more or less constant results around 880KByte/s download speed on the client, which equals plusminus to 70% of the theoretical maximum throughput of my 10MBit uplink. As the UTM also has some other WAN traffic, and we may have to add some overhead to the RED tunnel I guess this result is quite ok.

Only case I got a drop around 10-15% of the throughput was, when I lowered the MTU on the UTM WAN Interface down to 1350. In the other hand the RED itself interestingly seems to be more or less resistant to any MTU changes down to 1350 (no difference in throughput)

That TCP Window Scaling did not have a effect on the tunnel itself was predictable, as the Tunnel is UDP and therefor stateless anyway. But usually it has effect for the TCP connections inside the RED Tunnel - even if there was no visible impact at this speeds.

I also filtered on the UTM WAN Interface and the RED Interface for icmptype 3 / icmpcode 4 (need to frag) - but it seems, that there also ocurred no fragmentation

# tcpdump -nni eth1 -e icmp[icmptype] == 3 && icmp[icmpcode] ==4

So my new favored guilty components where I would start to dig is:
"
c) Your ISP (or a maybe crappy DSL/cable Router) which is throttling/dropping for some reason UDP packets
"

or

Or your constellation really triggers a Issue with RED, which may be solved in UTM9.2

BTW: As you have QoS active anyway on your UTM's WAN Interface - try what happens, if you activate the "Download Equalizer" Feature in QoS for your WAN Interface...[H]

@Bob:
That's true - he didn't mention the DoS Protection...I was once again typing faster than thinking [:D]

@Astaronator:
I  had yesterday little time to play around with one of my RED10 between Office (75/7,5 MBit Cable Line / default MTU 1500), and my UTM 9.2 Beta (9.171) on a 100/10 MBit Cable Line - also default MTU1500.

As UTM9.2 contains fixes and optimizations for the RED anyway (I love the new compression feature ;o)), I'm not sure, that the 9.1 Release behaves same. 

However I did tests with:
- lowered the MTU of the WAN Interface of the Router in front of the RED down to 1350 but UTM still with 1500
- lowered MTU of the WAN Interface of the UTM down to 1350 but Router in front of the RED with 1500
- tested both above with TCP Window Scaling enabled and disabled
- tested with global ICMP settings all off / all on 
- Tested with QoS on the UTM WAN Interface with Auto Tuning Options on and off

And interestingly the RED seems (at least with the used 9.2 beta) to behave extremely constant - independent of all the settings I changed. I tested the speed by copying a large .mkv movie from my NAS@home to the Office client behind the RED and always got more or less constant results around 880KByte/s download speed on the client, which equals plusminus to 70% of the theoretical maximum throughput of my 10MBit uplink. As the UTM also has some other WAN traffic, and we may have to add some overhead to the RED tunnel I guess this result is quite ok.

Only case I got a drop around 10-15% of the throughput was, when I lowered the MTU on the UTM WAN Interface down to 1350. In the other hand the RED itself interestingly seems to be more or less resistant to any MTU changes down to 1350 (no difference in throughput)

That TCP Window Scaling did not have a effect on the tunnel itself was predictable, as the Tunnel is UDP and therefor stateless anyway. But usually it has effect for the TCP connections inside the RED Tunnel - even if there was no visible impact at this speeds.

I also filtered on the UTM WAN Interface and the RED Interface for icmptype 3 / icmpcode 4 (need to frag) - but it seems, that there also ocurred no fragmentation

# tcpdump -nni eth1 -e icmp[icmptype] == 3 && icmp[icmpcode] ==4

So my new favored guilty components where I would start to dig is:
"
c) Your ISP (or a maybe crappy DSL/cable Router) which is throttling/dropping for some reason UDP packets
"

or

Or your constellation really triggers a Issue with RED, which may be solved in UTM9.2

BTW: As you have QoS active anyway on your UTM's WAN Interface - try what happens, if you activate the "Download Equalizer" Feature in QoS for your WAN Interface...[H]