QOS for PCoIP on a 3850

[Stephen Carville]

Teradici advises that packet loss be kept below 1% in PCoIP. I know that UDP is not guaranteed to arrive in order but, again according to Teradici, out of order packets may be considered as dropped packets.  One suggestion is to turn on WRED on the 3850 but version 03.03.04SE of the IOS doesn't support this.

How can I enable this?

[Joseph W. Doherty · Accepted solution]

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

Well, if the 3850 doesn't support WRED, then the answer to your question for how to enable is you don't.

That noted, it's unclear how WRED activation, if available, will help guarantee UDP packets are delivered in order, or how it will guarantee PCoIP packet loss be kept below 1%.

What you might do on a 3850, is place your PCoIP traffic into a class that guarantees sufficient bandwidth that PCoIP traffic won't be dropped.  (Basically you should treat PCoIP somewhat like VoIP bearer or interactive video, i.e. delay and drop sensitive.)

Out-of-order delivery isn't a possibility unless you have multiple paths and/or reorder transmission of packets part of the same flow.  Network devices usually, by default, will not resequence a flow's packets.  The only time that "normally" happens is if there's a change in the logical or physical topology while packets are "in flight".

[Stephen Carville]

Thank you.

There is considerable out-of-order delivery between the remote site in North Carolina and the network center in California.  The frustrating thing is it only happens in one direction NC->CA but not CA->NC.   I guess I was grasping at straws.

[Joseph W. Doherty]

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

Ah, well that's unusual and often not a good thing.

You might want to try to identify the hop that is doing it.

A common cause is something with multiple paths and with something like CEF packet-by-packet forwarding enabled.  This is done for "better" multi-path load balancing, but it tends to cause issues with traffic that's delivery sequence sensitive.  (NB: Even TCP's performance can be impacted as it will incorrectly assume, in some such cases, that packets have been lost when received out of sequence.  It will recover, and it will insure packets are received in-order, but it can really degrade TCP end-to-end performance.)