On 31/3/09 9:00 AM, "Philip D'Ath"
Predominately I've used QoS to guarantee delay, latency and jitter. I've also used it to protect certain types of network traffic (ssh and routing protocols, so I can guarantee they will work under excessive load). I don't think I have ever used it to determine traffic to drop (although it can obviously be used for that). If a customer is reaching the point where their pipes are so saturated they are losing traffic then they should upgrade to the next size pipe.
I've never ran into a case where the "pipes" where so big that QoS was not required. Never.
Mostly agree Philip. On a point to point link, sufficient bandwidth means not having to worry about QoS. However, for a multipoint you can always create a situation where there is insufficient bandwidth, though in practice, sufficient bandwidth generally works. There is a view that QoS is simply priority, and that QoS is a way of managing bandwidth. I disagree with both of those views. For some types of traffic, it's better to delay than to drop: "better late than never", while for other types---such as isochronous streams---a late packet is a missing packet: "Better never than late". In fact, for such a stream, it's almost equally bad to deliver the packet too early. I'd much rather define traffic classes so that the appropriate characteristics are delivered, as required by the application---and furthermore, that it's up to the application to determine what these are. A trap with the QoS = Priority view is that you use it to manage insufficient bandwidth. If the network is 80% full, that means it's 20% underutilised, and by using 'smart' equipment you can use that 'spare/unused/wasted' 20%. I.e., a 'smart, slow' network is better than a 'dumb, fast' network. My experience is the opposite: 'dumb and fast' is not only better than 'smart and slow', it's also considerably cheaper. That '20% unused' isn't unused---it's just the way packet networks operate. Of course, sometimes physics steps in and you are stuck with a slow copper line and Shannon-Hartley---at which point QoS may be the least worst option. -- Michael Newbery IP Architect TelstraClear Limited TelstraClear. Simple Solutions. Everyday Residential 0508 888 800 Business 0508 249 999 Enterprise & Government 0508 400 300 This email contains information which may be confidential and subject to copyright. If you are not the intended recipient you must not use, distribute or copy this email or attachments. If you have received this email in error please notify us immediately by return email and delete this email and any attachments. TelstraClear Limited accepts no responsibility for changes made to this email or to any attachments after transmission from TelstraClear Limited. It is your responsibility to check this email and any attachments for viruses. Emails are not secure. They can be intercepted, amended, lost or destroyed and may contain viruses. Anyone who communicates with TelstraClear Limited by email is taken to accept these risks.