Wireless router with *incoming* QOS

[rogerbinns]

Almost all the devices provide outgoing QOS, which roughly amounts to ordering the traffic to be sent according to configured rules.

I am looking for incoming QOS which means the device will have to deliberately discard or delay lower priority traffic already received from the WAN before sending it to local machines. That will then cause those flows to reduce sending speeds at the other end of the link. (It can also be implemented by messing with acknowledgment packets from the local network).

An example of this is Hulu traffic which is on port 1935. All the data comes from the Internet with only acknowledgments sent in return. Obviously outgoing QOS is useless and for incoming traffic I want port 1935 to use as much as it wants with other traffic using whatever is left.

 

[thiggins]

There is no such beastie. But see Taming Your Network's Bandwidth Hogs - Part 1.

I looked at DD-WRT, but the QoS controls appear to be uplink only. I could be confused by the "WAN" and "LAN and WLAN" terminology in the controls.

 

[EricE]

Dunno about the mainstream routers, by you can build a firewall around http://m0n0.ch/wall/

M0n0wall supports QOS in both directions. You can see a demo of it's QOS capabilities here.

Pick up a fan less PC like several outlined on the hardware page and it's plug and play - download an image, write it to flash, boot and off you go. A little harder then a linksys or dlink router, but not by much. You get a much more flexible system with greater functionality. Had mine for a year now - I love being able to VPN to my m0n0wall firewall from my iPhone to secure all my traffic when I am hopping from wireless net to wireless net.

 

[thiggins]

Dunno about the mainstream routers, by you can build a firewall around http://m0n0.ch/wall/

Actually, that's basically what I did in this article, but with pfSense.

 

[EricE]

Actually, that's basically what I did in this article, but with pfSense.

Hmm, unless I am missing something, those solutions seem to be one direction only (the OP's original complaint) whereas a m0n0wall based solution will work in either direction.

EDIT: BTW - nice site - I've really been enjoying several of the articles here.

 

[thiggins]

The example that I used was throttling BitTorrent downloads. pfSense is a fork of m0n0wall. Basically, all of m0n0wall's functions, but aimed at running on a standard PC instead of a single board computer.

Glad you like the site.

 

[mgraves]

My understanding is that you really can't effectively limit your downloads. That is, your ISP sends stuff as fast as the link to you supports.

Almost all traffic shaping that I've seen focuses on managing upload traffic since asymetrical links like cable modems or ADSL pose certain problems for time sensitive traffic like streaming audio or video.

BTW, m0n0wall itself has releases for plain old PCs as opposed to an SBC.

 

[thiggins]

My understanding is that you really can't effectively limit your downloads. That is, your ISP sends stuff as fast as the link to you supports.

How do you explain the WAN > LAN shaping in m0n0wall and pfSense then?

Sure seemed like it worked, to me.

 

[rogerbinns]

It looks like from various web postings that DD-WRT does indeed support incoming QOS. As I pointed out, it is also messy to implement as you basically need to convince the sender to send less traffic. This can be done by discarding already received traffic as the sender will then realise there was packet loss and send at a slower rate, although that was wasteful discarding the already received traffic.

It is also possible to do by playing a far more invasive role between sender and recipient by modifying the packets going in either direction, especially acknowledgements. Current TCP stacks include timestamps in efforts to send the optimum amount of traffic so by detecting and manipulating those you can shape the connection, although it may also require delaying some traffic rather than just frigging with headers to make it look delayed.

However on further inspection I don't think my use case of Hulu would work anyway. It uses a variable rate and monitoring with nethogs on my Linux client with an otherwise idle connection shows bandwidth being between 24 and 207 kilobytes per second depending on scene and audio complexity. (207 kb/s is the maximum my dsl can do). It also appears to buffer only a few seconds ahead rather than a certain amount of data ahead. Only a router than actively played with the connections would be able to rapidly reduce incoming data of other connections.

I also don't use monowall or any of the similar systems. Compared to a standard Linksys box they cost way more and consume way more power. I already have a server on 24 hours a day and port forward services to it as appropriate. The usual load could be handled by a "trivial" machine, but the peak can't. I use it for the following:

• DNS
• IMAP and IMAPS
• SMTP and SMTPS
• Music server
• DHCP
• TFTP and NFS for network booting
• Web server
• Web gallery (image processing, MySQL backend)
• Samba server
• Print server
• Squid
• Filtering proxy
• SSH
• Backups
• Source code control server
• File server (30GB of photos, 23GB of music, way more of camcorder footage, video projects, 81G of cd images)

So I'll have to just keep doing what I have been so far and only use my net connection for one thing at a time.

BTW Tim if you do want to do real world testing of incoming QOS then Hulu is a great test case. Just play a video in 480p quality and also run bittorrent. Hulu should play just fine if nothing else uses the connection so any stuttering while doing bittorrent will be an indication of incoming QOS not working sufficiently well. You can also do video calls with Skype but it prefers to use UDP so that is harder to shape.

 

[Esurnir]

Bell Canada traffic shaping work very fine indeed, and they dont inject any reset packet.

But from reading the TCP specification, well the routing software just need to change the tcp window size of your acknowledgement packet and then the traffic will slow down.