For many of the Skype for Business and Lync readers out there, you may think to yourself, “Hey, I’ve seen a similar title like that before…”, and you would be absolutely correct. During Lync Conference 2014, Lync MVP Jeff Schertz gave a fantastic presentation about “Video – What in the World Are You Doing to My Network” in which he gave a deep-dive into the impact of Lync’s new H.264 SVC video codec and how that impacts network bandwidth across the enterprise. While it is absolutely accurate that video can stress enterprise networks, the often forgotten (and sometimes neglected) truth is that app share traffic in Lync/Skype4B has a far greater impact (in my opinion) to impact overall bandwidth figures. What follows is my attempt not to reduce video planning but to place an equal (and maybe higher) importance on planning for application sharing bandwidth in Lync/Skype4B deployments.
Foundational Concepts of Application Sharing
Application Sharing has existed, in one form or another, since the Live Communications Server days and has received updates and/or changes with each iteration of the product (OCS, OCS R2, Lync 2010, Lync 2013). Some of those largest changes include:
- Migrating from the NetMeeting protocol (H.323 based) in LCS 2005 to RDP (ITU T.120 based) within OCS 2007 R2 (also Lync 2010/2013 and Skype for Business).
- Including formal meeting desktop sharing natively within Lync 2010 instead of relying on the LiveMeeting application.
- Adding a high performance P2P desktop sharing in Lync 2013.
As stated above, application sharing in the current iterations of the Microsoft UC stack are based off the Remote Desktop Protocol. IT administrators across the globe utilize RDP every day for connecting to servers and workstations and are, as a result, very familiar with the overall capabilities offered. At its core, RDP has the following characteristics:
- RDP is delivered over the Transmission Control Protocol (TCP).
- RemoteFX was added in recent RDP clients to enhance the RDP experience by offering User Datagram Protocol (UDP) delivery.
- Configurable performance parameters in the RDP Connection client.
Generally speaking, the RDP protocol is fast, flexible and sufficient to deliver screen sharing across a wide variety of environments. Lync/Skype4B architects should exercise caution however, as there are significant differences in how RDP works and how Lync/Skype4B utilize RDP.
Foundational Concepts of RDP within Lync/Skype4B
While RDP is the foundation of application sharing used within Lync/Skype4B, there are differences in how the UC clients utilize RDP vs how RDP may be available through applications like Remote Desktop Connection.
Lync/Skype4B utilizes application sharing over TCP only
- RDP is encapsulated into TCP-based RTP packets.
- TCP is a connection-based protocol.
- Every single TCP conversation on a network involves a three-way handshake. This handshake is utilized to ensure the remote endpoint is ready to receive data and ultimately delays the start of data transfer at the expense of guaranteed readiness.
- TCP guarantees data delivery. If data is lost on transmission, the remote endpoint reports back to the sender that data needs to be re-sent – This behavior is great for data but is not ideal for real-time applications.
- Due to the guaranteed delivery mechanisms of TCP, data is generally sent in “chunks” instead of being sent as a stream (in UDP). This behavior can lead to additional latency and slower performance.
- UC TCP communications can be multiplexed over a single port.
- This allows Passive (Viewer) and Active (Presenter) to be done over a single port instead of requiring individual, unique ports in UDP.
- UC TCP communications can be firewall-friendly by utilizing RTP over TCP port 443 when direct connections between hosts aren’t available.
- Despite this “friendliness”, beware of application layer firewalls that may try to intercept/manipulate traffic and cause failures in application sharing.
RDP performance isn’t “adjustable”
Almost every IT administrator has seen it within the normal Windows RDP Connection application – a tab called “Experience”. This configuration allows you to tailor the connection for the bandwidth available on your connection to best optimize performance of the RDP session. Lync/Skype4B, however, doesn’t get to take advantage of those configuration settings and instead is limited to utilizing the following protocols/configurations:
- MS-RDPBCGR
- RDP encryption must be turned off.
- RDP Bulk Data Compression must be turned off for data between Viewer and the MCU.
- RDP Bulk Data Compression must be turned on for data between the Sharer and the MCU.
- MS-RDPEMC
So how does this impact my bandwidth estimations?
Microsoft (and many others) go to great lengths at describing bandwidth required for Lync/Skype4B but mainly restrict that description for audio/video related modalities:
If you search for information on application sharing bandwidth, you’ll likely come up with very few pieces of information. That information is actually hidden within two pieces of official Microsoft documentation:
- Lync 2010 and 2013 Bandwidth Calculator
- Network Planning, Monitoring, and Troubleshooting Lync Server
In both pieces of documentation, Microsoft explicitly outlines bandwidth estimations for application sharing traffic:
Table 1 – Application Sharing Bandwidth Estimations
| Screen Size | Acceptable | Optimal |
| 1280×800 | 384 Kbps | 1.5 Mbps |
| 1440×900 | 512 Kbps | 2 Mbps |
| 1680×1050 | 768 Kbps | 2.75 Mbps |
| 1920×1200 | 1 Mbps | 3.5 Mbps |
If you look at the info above, a few points can be made…
RDP bandwidth is variable in nature and can have a wide range of bandwidth requirements
There’s no denying that a static, non-moving screen won’t require much bandwidth, but movement of applications and refreshing of screens could require a dizzying 300% (or more) increase in bandwidth requirements. Don’t always assume the lower value is a hard-and-fast-rule – it’s really more an average towards the left side of the Bell Curve. Bandwidth above the average can (and will) occur.
Bandwidth requirements are most largely coupled to screen resolution
The higher the resolution, the more bandwidth required. Simple as that.
Screen resolutions continue to increase (4K or 8K screens, anyone?) and so too will bandwidth requirements
As users continue to receive laptops and/or monitors with 1080p (or better) resolutions, the likelihood of the lower resolutions being used lessens with each generation of products. It is difficult to argue that most users don’t at least have a 1680×1050 resolution today and even more difficult to argue that users won’t have higher resolutions in the future.
What makes it “Acceptable” vs “Optimal”?
Sadly, I cannot give an official answer on this but I can say through various rounds of testing these values that the “Acceptable” numbers provide a decent user experience whilst maintaining lower bandwidth. If you go much lower than those numbers, expect users to complain of slow refresh rates, jumpy application sharing, and/or wholly unusable application sharing sessions. If you want smooth application sharing, then you should plan for the “Optimal” numbers above.
What about that High Performance application sharing you talked about?
The bandwidth numbers above are all based off the basic frame rate of 2.5 fps that is default for all versions of Lync and Skype for Business. When Microsoft added the high performance application sharing capabilities they added the ability to allow a frame rate of up to 10 fps by enabling the appropriate policy configurations. This configuration allows very smooth and fluid sharing sessions but be prepared to pay for it – in my testing I regularly see up to 10 Mbps of bandwidth when the monitors are 1080p resolution.
How is Application Sharing different than Video?
While application sharing is similar to video, there are distinct differences in how the two modalities are implemented within Lync/Skype4B and thus two very different bandwidth patterns begin to emerge. The most obvious difference between the two is that different codecs are utilized, RDP vs H.264 SVC, which does have an impact on overall bandwidth numbers. Despite different codecs being a factor, the most significant difference is due to the intelligence the UC clients have when it comes to video.
P2P video bandwidth is directly proportional to the size of the call window on your screen. P2P application sharing bandwidth is directly proportional to the resolution of the sharer’s monitor.
By itself this may seem like a trivial difference but because Lync/Skype4B only requests sufficient bandwidth to fill the size of the video window, you end up very large differences in bandwidth consumption when the video window isn’t significantly altered and is left at default. For example, assume two users have 1080p monitors and initiate a video call to one another… In that scenario when users accept the video call the window starts out at a default size that will consume roughly 400-500 Kbps per video stream (per Table 2).
Table 2 – P2P Video Bandwidth Figures
| Window Size | Average Bit Rate | Maximum Bit Rate |
| Default | 115 Kbps | 499 Kbps |
| Resized | 596 Kbps | 814 Kbps |
| Maximized | 1727 Kbps | 2768 Kbps |
| Full Screen | 2888 Kbps | 4415 Kbps |
Assuming the users never resize the video window, initiating an application share during that call will result in an additional 1 Mbps to fulfill 1080p resolution requirements and will vary from 1-3 Mbps during normal application sharing usage such as minimizing/maximizing windows on the actively shared screen (per Table 1). When you begin to compare the two modalities it becomes very obvious how application sharing bandwidth can easily surpass video bandwidth.
Multiparty video bandwidth is directly proportional to the number of users in the conference AND whether application sharing is utilized. Multiparty application sharing bandwidth is directly proportional to the resolution of sharer’s monitor.
Thanks to Jeff Schertz’s presentation it is possible to see that bandwidth changes significantly as more users are added to a video conference, and in most cases the bandwidth drops. The bandwidth reduction is, again, the result of the clients only requesting sufficient bandwidth to fill the size of the video window and due to the fact that each additional user must occupy the same screen real estate as the rest of the video streams which results in lower resolution streams being utilized.
Table 3 – Multiparty Video Bandwidth Figures
| Conference Size | Average Bit Rate | Maximum Bit Rate |
| 2 | 2128 Kbps | 4063 Kbps |
| 3 | 4050 Kbps | 5890 Kbps |
| 4 | 1304 Kbps | 2860 Kbps |
| 5 | 1224 Kbps | 2699 Kbps |
| 6 | 1565 Kbps | 3017 Kbps |
When application sharing is added to a conference, the video bandwidth numbers again change due to the changing proportions of screen real estate for each modality. When application sharing takes over the Gallery View video streams are moved to the top of the window and shrink due to the increased presence of the application share.
Figure 1 – Example of Gallery View with Application Sharing
In most scenarios involving application sharing within multiparty video conferences, you’ll see video resolutions and frame rates begin to change which results in video bandwidth taking a nosedive.
Table 5 – Multiparty Gallery View Video w/Application Sharing Bandwidth Figures
| Conference Size | Average Bit Rate |
| 2 | 250 Kbps |
| 3 | 375 Kbps |
| 4 | 500 Kbps |
| 5 | 625 Kbps |
| 6 | 750 Kbps |
Note: I’m current conducting further testing on these numbers. Please consider these preliminary for the time being.
Assuming again that 1080p resolutions are available to end users, initiating an application share during that call will result in an additional 1 Mbps to fulfill 1080p resolution requirements and will vary from 1-3 Mbps during normal application sharing usage such as minimizing/maximizing windows on the actively shared screen (per Table 1). In certain conference sizes you can have application sharing dwarfing the video bandwidth requirements by 300-400%.
Video usage is a very subjective use case in most organizations. Application Sharing is far more common for most organizations.
In many organizations video simply isn’t that common. Sometimes that is because of technical limitations (such as perceived lack of bandwidth) whilst in other cases it is due to a user culture that simply doesn’t want to utilize video. More often than not I see organizations broadly adopting application sharing whereas video remains a very small deployment. This may change over time, especially with the new generation of Millennials entering the workspace, but the hard truth is that application sharing is used far more frequently in organizations and video is an afterthought or edge case.
Show us the math!
Where all of this becomes apparent is when you start computing numbers within the Lync Bandwidth Calculator. The calculator works off of the “Acceptable” numbers in the table above and includes complex calculations for how users handle video when in a multi-view configuration.
Peer-To-Peer
Assume that you have two branch sites and a separate data center site. Users in each site regularly exchange P2P traffic including audio/video/application sharing. Also assume that these users are huge fans of Lync/Skype4B and that 5% of users in each site are utilizing the features concurrently. Lastly assume that there’s about 300 users in each site, which results in the numbers below:
| Site | Peak Audio BW (Mbps) | Peak Video BW (Mbps) | Peak AppShare BW (Mbps) |
| Site 1 | 0.51 | 10.04 | 17.00 |
| Site 2 | 0.51 | 10.04 | 17.00 |
61.7% of all bandwidth required is for application sharing! Additionally, that’s only using the Acceptable bandwidth calculation of 1 Mbps for the 1920×1200 resolution monitors the users have! If you start computing numbers based on the Optimal bandwidth calculation it becomes even more lopsided with the Application Share bandwidth tripling.
Conferences
Assuming the same scenario above, the numbers will change significantly when conferences are involved. Much of this deals with the fact that the Lync client and AVMCU actually use less bandwidth for video as each additional user is added to the conference and even less bandwidth when application sharing is invoked.
Assuming the same 300 user count at each site we end up with the numbers below:
| Site | Peak Audio BW (Mbps) | Peak Video BW (Mbps) | Peak AppShare BW (Mbps) |
| Site 1 | 0.42 | 5.45 | 17.00 |
| Site 2 | 0.42 | 5.45 | 17.00 |
74.3% of all bandwidth required is for application sharing! Additionally, that’s only using the Acceptable bandwidth calculation of 1 Mbps for the 1920×1200 resolution monitors the users have! The large sucking sound on your network – it’s application sharing, not video.
You’ve proven your point, so now what?
I can’t overstate the importance of properly planning for application sharing bandwidth in addition to the rest of the bandwidth calculations required for Lync/Skype4B. As a result of this it’s important to begin asking the following questions:
- What’s the most common resolution of monitors deployed within your organization?
- Do we have sufficient bandwidth to support sharing with that resolution?
- Do we intend on utilizing Quality of Service with application sharing?
- How does our user culture view video vs application sharing?
Once you begin to answer the questions above you can begin to properly plan for bandwidth for application sharing. Many customers I work with are often surprised at the numbers because they are so focused on the fear about bandwidth requirements for video, but in reality video bandwidth is likely to be a lesser concern when compared to application sharing bandwidth. In a future article we’ll discuss methods you can utilize to help control application sharing bandwidth for both on-premises and Office365 deployments. Stay tuned!