noticeable difference in desktop sharing performance on premise / via edge

[David Phillips]

On premise implementation.  

I noticed recently that when a screen sharing session drops from VBSS to RDP for whatever reason, while there's an expected frame rate drop for clients connected on-net, there's a major performance drop for clients connected via the Edge.  For example, when someone types in a command prompt, it takes five to ten seconds before external viewers even see the entire line of text.  When moving a window around, the screen paints very slowly as well.  It is almost unusable.

I can reproduce this on multiple internet connections.  It doesn't happen while in VBSS mode.  Network bandwidth is good.  Internal QoS policy is good.  

Am I missing a setting somewhere?

[#2]

Just an update on this one - I narrowed this down to being an issue (at least externally) with SfB client users on a Surface Pro or 4k screen.  

Unfortunately we still get random reports internally of SfB screen sharing getting really bad.  10 second delays / screen tearing / even fully freezing up.  Has anyone seen an uptick in reports of screen sharing issues like this?

[#3]

 Based on this statement from support.office.com, "Not only is VbSS faster, but it also more reliable and works better in case of low network bandwidth conditions.", I had high hopes for VbSS, but as we rolled out Office 2016 (now virtually 100%), it seems like we are having more screen share problems rather than fewer.  Many of the same issues that David Phillips mentions (10 second delays / screen tearing / even fully freezing up).  It also seems that forcing the meeting back to RDP/TCP, either with a registry change or by doing 'request control'-'give control'-'take back control' in sequence has helped resolve the issues.

My environment is global, thousands of associates, all Office 365 Online (no on-prem).  Any insights from anyone would be appreciated.