Silently dropping QoS marked packets on the greater Internet

Fri Sep 2 16:17:51 UTC 2011

On (2011-09-02 12:02 -0400), Valdis.Kletnieks at vt.edu wrote:

> Except you can't actually *guarantee* that QoS works every packet, every time,
> during congestion even within the same network. Remember - QoS is just a
> marking to shoot the other guy first.  If a link ends up overcommitted with QoS
> traffic, you're still screwed.  And there's a second-order effect as well - if

I guess you're trying to say, if the protected traffic class is out-of-contract
you're still out of luck, that is true.
If you're trying to say that any link which which is overcomitted is lost cause
anyhow, QoS or not, this of course is not true, if link is not overcommitted
QoS makes no sense.

> your net is running sufficiently close to the capacity edge that QoS actually
> matters, there's probably other engineering deficiencies that are just waiting
> to screw you up.

Lot of customers have low speed DSL connections and want to run VoIP over 
that, even if whole office is surfing lolcats.
This works, and it works perfectly when configured correctly, of course if VoIP
traffic would exceed capacity, you're still screwed, this is where planning
comes in, you will sell only X VoIP lines which will always fit, just lolcats
will load slower.
If this link gets uncontrollable priority traffic from Internet, all bets are
off, hence the options in the first post

-- 
  ++ytti