how-to block ads
|
|
Uniqs:
161 |
Share Topic
 |
 |
|
|
| QoS What most people fail to realize is that QoS/CoS/priortization of traffic doesn't kick in on an ISP's backbone until the backbone is congested.
Right now, many of the large ISP's prioritize their own video and voice traffic so that it always has priority. So if a link of theirs happens to get congested, their most important traffic, which most of their subscribers use, will get there.
So if ISP's decide in the future that they are going to run their backbones and the links down to aggregation routers at full capacity, then packet prioritization will be something for us to worry about. Because it means general Internet traffic can come to a crawl at any time, or be that way most of the time.
I suppose ISP's can choose to have the poor service available. But it is a nightmare to run your links at full capacity for any amount of time. And QoS is only going to kick in when links are full. If there is any bandwidth available, there is no need for prioritization to do its work. But as soon as one packet has to be dropped because of congestion, QoS kicks in and drops or slows packets with the lowest priority.
To me, the bad thing that will come out of this is that large companies will be paying for prioritization of their traffic, and will basically be paying for nothing. Because no one in their right mind is going to run a backbone with links at full capacity. Not on purpose anyway. | |
 tubbynetreminds me of the danse russePremium,MVM
join:2008-01-16
Chandler, AZ | What most people fail to realize is that QoS/CoS/priortization of traffic doesn't kick in on an ISP's backbone until the backbone is congested.
not quite. packet classification always occurs (if it is done) on the packet as it ingresses to the providers network. if the isp is dropping the packet into given queues, that will be added to the appropriate field and then each successive device trusts the dscp markings within the transit network. traffic like real-time voice and video will always jump in front of bulk transfer.
But it is a nightmare to run your links at full capacity for any amount of time. And QoS is only going to kick in when links are full. If there is any bandwidth available, there is no need for prioritization to do its work. But as soon as one packet has to be dropped because of congestion, QoS kicks in and drops or slows packets with the lowest priority.
also not entirely true. the issue is that each interface on each linecard has a given buffer depth. with no qos applied, the full size of the buffer is allowed for queueing -- there is no priority. once qos is applied, the buffer is carved up into chunks, one for each of the different classes. if the bulk transfer queue is full, even though the link utilization is low, you'll still see drops on the bulk transfer. the issue with qos is that it must be done with either (a) intelligent network analysis to determine peak requirements for each queue or (b) a linecard with immense buffer depth so carving isn't an issue.
q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..." | |
|
