CoS, what is it good for? Maybe not “absolutely nothing” but not far short.

With the exception of the EF class for real-time apps, CoS actually delivers almost none of the expected benefits promised by the marketing gloss. Let’s pull it apart and see why.

CoS only operates on outbound links (no point in queuing traffic after it’s already traversed the WAN). OK, but managing traffic outbound from each end does give bi-directional control, right? Wrong. CoS bandwidth allocations are proportional to the overall outbound bandwidth which is usually much bigger at the DC end than any of the branches. Traffic in any individual CoS leaving the DC could easily flood the smaller inbound branch links.

OK how about outbound from the branch? Nope, not much better. Normally the outbound branch traffic runs at a lower volume than inbound. CoS only kicks in when the link reaches capacity and this rarely happens. Worse still, the sum of many branch networks can oversubscribe the inbound DC bandwidth and as there’s no inbound control at the DC end the traffic profile can be chaotic.

In summary, CoS has no meaningful control of traffic outbound from the DC or outbound from the branch. CoS cannot help with inbound control. Include the possibility of branch to branch traffic wrecking best laid plans and any notion that CoS is useful flutters out the window.

If you want to monitor CoS utilization and other end-to-end Path characteristics like packet loss, RTT and jitter try PathView . If you need to manage traffic it’s far better to use traffic engineering devices like PacketShapers, even if you can only put one in the DC. We provide PathView and PacketShapers separately or bundled in low cost service options.