Joe Abley wrote:
On 30 Mar 2009, at 16:00, Philip D'Ath wrote:
I've never ran into a case where the "pipes" where so big that QoS was not required. Never.
That's presumably why you have needed to worry about QoS. Buy bigger pipes. :-)
If you're constrained (by what the telco will give you, by what you can afford, by what your vendor will support) to pipes that are too small, then sure, it makes sense to concern yourself about which of your customers' packets you are going to give inferior service to in order to let the higher-value packets get the best treatment possible given the inadequate network.
We have an interesting network that's constrained. The last mile in places here desperately needs replacing, telco's that take their time with bandwidth upgrades, a user population that all arrives on the same day, and leaving on the same day, making capacity planning a nightmare, and all those other interesting realworld issues. The eventual goal is to have enough bandwidth, but getting from here to there is where the Fun Is(tm). (If it was easy, everyone would do it right?) Our solution was to develop a custom QoS solution based on Stochastic Fair Queuing, where instead of binning by 5 tuple, we bin only by destination MAC address. This means that users get exactly 1/nth of the available bandwidth. This worked out awesomely well, as in, we couldn't have asked for better. Users who are mostly idle get low latency, even tho other users on the network are busy torrenting (and experiencing high latency). Users who do "multithreaded downloading" etc don't get more than their fair share of the bandwidth. One improvement we'd like to make is to change it so within a "bin" (aka User), we reorder traffic so that we deliver traffic with v4 ToS bits asking to be delivered last is deprefed. This means the user still gets 1/nth of the traffic, but the individual user can use the ToS bits to select which traffic they receive first. Setting your ToS to say all your traffic is high priority doesn't get you any more of the link, and in fact would have no benefit. Setting your VoIP traffic to have low latency ToS, and your bulk downloads to have a "low cost" ToS, would deliver your VoIP packets first, and then when there are no VoIP packets, would get your bulk download packets. This seems to be the fairest possible solution we could come up with while we work on improving the amount of bandwidth through our network.