Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Unfortunately, what a provider spits out (for markings) doesn't indicate they are treating the marked traffic correctly. To verify correct provider treatment, I've found this can be done by sending various combinations of various class traffic, to verify what comes out is as expected. For example, if I send VoIP class traffic that's less or equal to the agreed subscription rate for that class, I should be able to overrun one or more other classes and still obtain expected performance for the VoIP traffic. If I don't get these results, provider needs to do some explaining. (Note - to do these kind of tests you need to know (control) end-to-end traffic rates, i.e. an active multipoint can be difficult to test. Additionally, these kinds of stress confirmation tests can easily be disruptive to other production traffic. Ideally, such testing only has known quantity of test traffic.)
PS:
I once spent 3 months arguing with a tier-1 MPLS international provider that one of our connections to their MPLS cloud didn't seem to be working 100% correctly. They swore up, down and sideways, nothing wrong with their network. Eventually, they found a line card with out-of-date firmware (for the card) was very occasionally corrupting packets when under high load. They updated the firmware; end-to-end behavior finally became as I expected.
On multiple occasions, with them and other tier-1 WAN cloud providers (frame-relay, ATM, MPLS, MetroE), encountered minor provider configuration errors such that, again, end-to-end performance was less than I expected. One time just one link of a bundle (forget whether it was MLPPP or ATM IMUX) was misconfigured. Difficult for me to identify, but once I did, they quickly saw the issue, unlike the firmware issue above. I.e. these type of errors normally required me finding the link that wasn't quite up to snuff, but when I did, the service provider would quickly "see" and correct the problem.
