[afnog] Prioritization

[Mark Tinka]

On Monday, September 12, 2011 06:37:00 PM david aliata 
wrote:

> Hi Guys,

> For the Cisco gurus.Could someone please give me a lead
> on how I can prioritize and test WebEx, Skype and some
> two websites on Cisco equipment. My set up is such that
> the link goes to a Cisco

> 1941 router>Cisco ASA 5505>Cisco Catalyst Switch
> 2960>Computer.

Hmmh, lots of challenges:

	a) Skype, WebEx and those web sites are on the
	   Internet. There are no guarantees of end-to-end
	   quality on Internet traffic, as an ISP has no
	   control of traffic it hands off/receives from
	   it's peers/upstreams. You can really only provide
	   control inside your network only.

	b) It is easier to implement QoS on egress, as
	   traffic is entering your network from your
	   customers, as it will traverse your network.
	   However, at the point where you hand it off to
	   your peers/upstreams, you lose any effects of
	   that QoS applied earlier.

	c) Implementing QoS on ingress is difficult as you
	   need to identify the traffic you want to
	   prioritize, somehow. It could be at various
 	   layers of the OSI model, e.g., IP address,
	   TCP/UDP port, application (using NBAR), e.t.c.
	   This may not always be reliable, especially for
	   online sites that rely on CDN's like Akamai,
	   Limelight, e.t.c.

	d) In your network, you need to implement QoS
	   (proper) on every node the packet is going to
	   touch. From your topology, that means your ASA
	   firewall too, as well as your Cisco switch. The
	   problem is that QoS support in these systems may
	   be far below what you can get in the router.


Having said all that, it is likely you have more bandwidth 
inside your own network than to your peers/upstream, e.g., 
100Mbps or 1Gbps in your LAN vs. something less toward your 
peers/upstream. So QoS, which is mostly really effective 
inside your network, will not do much inside your under-used 
network.

Sorry if I'm being pessimistic, but QoS for Internet traffic 
is really hard to do, as you just can't guarantee that other 
transit networks aren't dropping packets or adding latency 
unnecessarily. In reality, your best bet for getting good 
service is:

	a) Sufficient bandwidth to your peers/upstream.

	b) No packet loss to the destinations you're trying
	   to reach.

	c) As low a latency value as possible to the
	   destinations you're trying to reach.
	
	d) As low a jitter value as possible to the
	   destinations you're trying to reach - given the
	   applications you mention, this can be a little
	   more elastic.


You may still go ahead and deploy QoS, but I can't promise 
you that things will evidently get better if they're bad, or 
better if they're not bad.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20110912/cad1baec/attachment.pgp>