Adobe Connect Standard View Bandwidth Utilization Estimates Illustrated

Introduction:

Adobe Connect bandwidth utilization will vary based on use case. Variables such as Meeting size, Connect features employed, disposition of clients and type of Connect server hosting, all have an effect on the network bandwidth utilized and as well as on where the bandwidth on a network will be most affected.

This article focuses on bandwidth and not on latency: Latency and bandwidth are different topics that are often confused or inappropriately lumped together. Although in some cases there may be a correlation between bandwidth and latency as when exceeding available bandwidth will drive up latency, nevertheless, the relationship between them is often inappropriately overstated. Bandwidth refers to the size of the network pipe while latency refers to the speed over the network or the time it takes for the data to travel. Connect clients with excess bandwidth may still experience latency with Connect for reasons unrelated to bandwidth such as network distance, transmission errors, resource performance (server, DB or client), maintenance schedules and imposed constraints such as QoS or blocking the RTMPS protocol and thereby forcing inefficient tunneling of RTMPS encapsulated in HTTPS.

Resources:

For information on latency see the following articles:

Tunneling with RTMP encapsulated in HTTP (RTMPT) should be avoided as it causes latency

Connect Meeting RTMP VS/VIPs on Load-Balancers

Adobe Connect Database Performance and Monitoring

 Connect on VMWare – some deployment tips

Below are some references on the topic of Connect bandwidth; these are often referred to as a general guide; the examples sited later in this article however are from baseline testing described herein:

Estimating Bandwidth Consumption in Standard View Adobe Connect Meetings

Best Practices for Adobe Connect

Adobe Connect best practices for large events and seminars

The Connect Cluster:

The context of the Connect bandwidth utilization is important and should be included among pre-deployment architectural considerations when rolling out Connect. There are basically two primary Adobe Connect deployment models for consideration: In the cloud and on-premise. The disposition of the clients attending the meeting has an effect where the on the network bandwidth will be utilized for any Connect Meetings or Webinars. To support these two broad deployment paradigms of cloud or local on-premise, there are three basic Adobe Connect licensing models.

1. Adobe Connect Multi-tenancy Hosted
2. Adobe Connect Managed Services (ACMS) single domain hosting
3. Adobe Connect On-Premise licensed single domain

Note: An Adobe Connect on-premise license need not only be deployed within the customer’s LAN infrastructure. Adobe Connect Partners offer Managed ISP hosting options and an on-premise license deployment can be cloud-based as well.

Cloud or LAN:

For the purposes of considering the relationship of bandwidth to architecture, an Adobe Connect cloud-based deployment and an on-premise deployment within a customer’s LAN present different concerns with reference to the disposition of bandwidth rather than with the specific license type.

Primary differences with reference to bandwidth when comparing cloud-based Connect server clusters with on-premise based Connect server architecture is with the handling of external clients and the direction of the network traffic. There will be less internal network traffic on the LAN when external users (with possible lower-impact exceptions such an SSO server) remain external. Note that VPN users in remote offices are considered internal users.

See the following diagrams comparing a 2-server cloud-based cluster with a 2-server on-premise cluster hosted on a customer LAN. Both assume the need for internal and external users to participate in Meetings.

Cloud-based:

With a cloud deployment, the external users have little or  no impact on the internal LAN of the Connect account owner. The biggest bandwidth hit is at the cloud-based hosting facility. The primary concerns for the Connect owner’s IT will be routing RTMPS around third-party proxy servers and making sure client profiles and other internal restriction, limitations and constraints do not prevent or enervate Connect usage:

LAN-based:

With a LAN-based on premise deployment, internal Connect users will normally have great performance on the average corporate back-plane by avoiding any mitigating and often unpredictable WAN variables. External users may be hosted on a reverse proxy Connect Edge server in the local DMZ to meet security requirements. All external traffic is terminated in the DMZ where the remote Edge server does all the heavy lifting. The Edge connections to the internal cluster consolidate the external connections and reduce the overall internal impact of external users by limiting them to the external firewall and DMZ:

Connect Standard View Meeting Features and Bandwidth:

Screen-sharing and the use of multiple live web cameras are the two most bandwidth intensive activities in any Connect Meeting or Webinar. The latter requires that a Meeting Host or Presenter project the client screen up to the Connect servers and then back down to each user in the Meeting. The more users with cameras, the more upload and download activity.

The features employed in any Connect Meeting determine the amount of bandwidth utilized.  Depending on the Connect use case, you could use between 5 to 10 Mbps per 100 participants. These general rules apply:

• • The typical average is 50 kbps per user
  • It depends on what Connect Meeting users are doing
  • For example, on the high end one client measured regularly uses 20 Mbps for 150 users in a Connect Meeting room.
  • More typically there is a max of 100 Mbps at the firewall (outgoing, incoming is never that high)
  • With just over 1000 users a safe estimate is < 100kbps per user totaling 12 MB
  • 5 Mbps per 100 is the low average (or 6MB per 1000 users using best practices for large Webinars).
  • Things like video and screen sharing tend to use more bandwidth
  • A one-to-many broadcast of an uploaded PowerPoint deck uses less bandwidth
    • PPTX should always be uploaded to the Meeting room
    • Do not present a PPTX using screen-sharing as it wastes bandwidth

Bandwidth Utilization Use Case Baseline Tests:

The following tests corroborate these guidelines listed above and offer a model to test bandwidth utilization for any Meeting or Webinar use case; it is prudent to do these type of tests with your specific use Webinar case as part of your rehearsals to get accurate bandwidth utilization baselines:

First bandwidth test: I uploaded a 15.5 MB PPTX to a Connect Meeting room and advanced thru all the slides while monitoring the download stream to each client; the average for each client was 50 kilobits; see below:

Second bandwidth test: I then tested with a camera pod set to the highest quality and wide screen option: Meeting>Preferences>Video; see my host camera settings below:

The average download stream at each client when I had the camera pod sized small in the upper corner of the meeting while flipping slides was under 200 kbps (kilobits); The host screen capture below corroborates; my host client in the Connect addin is pushing 121 kilobits up to the server; see below:

The average when I expanded the camera pod and moved around create some activity on screen (waving etc.) was 300kbps download streaming to each client; see below my upload from host client to server is 381 kbps; see below (wow- my hair is getting thin):

Note: Participants expanding the size of the video pod locally has no effect on bandwidth utilization, but hosts expanding the pod size for all does have an effect; Connect will ask for a resolution from the webcam that as closely as possible matches the size of the video pod.

Third bandwidth test: I then tested screen-sharing a slide deck from my desktop to simulate application sharing live demonstrations and found a significant variance based on the screen resolution of the host sharing the screen:

• Host screen-sharing at 1920×1080 resulted in an average  download to each participant of 700 kbps
• Host screen-sharing at 1288×768 resulted in an average download to each participant of 200 kbps
• The participant experience was very similar. I see no reason to waste the bandwidth on the higher host screen-resolution: Lower screen resolution resulting in very economical bandwidth utilization while sharing the screen
• See the bandwidth indicator while I share my screen flipping through multiple jpegs at 1288×768. I am pushing up 338 kbps to the Connect server while actively changing jpeg images on a second monitor that I am sharing.

Fourth bandwidth test: Video – I created an mp4 using the following settings: Appropriate quality settings are a major variable determining the amount of bandwidth used and the playback experience of mp4 video in Connect:

• I used: H.264, 720×404, Frame Rate 30, bitrate CBR, target rate 1Mbps, Key Frame Dist 90.
• Best practice encoding for video in Connect imperative: Rehearsal and testing of any Video used is prudent prior to any Meeting or Webinar. It is easy to test playback experience and bandwidth consumption per client participant. Note also here (in the highlighted bandwidth indicator) how my remote office client experiences some latency albeit manageable  (595kbps down) that not affect the video playback experience – no choppiness at all watching the pups wrestle (the Jack-Russell ends up winning although this capture shows him as the underdog):

Bandwidth Utilization Use Cases:

Using the baselines from these tests, here is a list of potential use cases from a recent customer inquiry with the predicted overall account-wide bandwidth usage estimates running Connect 9.5.

Case 1: A 1500 user seminar room with a PowerPoint and a desktop share:

Estimate: 1500 users x 50 kilobits each for the PPTX use case =75000 kilobits or 9MB. Add to that a desktop share with conservative screen-resolution (1280×768) 1500×200=300000 kilobits or 37MB. Add them together (75000+300000) for an average of 375000 kilobits or 47MB. Realistically it will be less at any given time because it is rare to simultaneously do both activities at once in a meeting. It is more common to share either flip PPTX slides or share an application thereby lowering the actual bandwidth utilized at any given time.

 Note: There is an important caveat with reference to an initial spike caused by the PPTX SWF download of 1000 kbps per client participant for a few seconds each. Assuming 1/3 at a time as participants enter the layout with the PPTX on stage in a share pod even if downsized in a corner or hidden behind another pod, and assuming that there will not be any screen-sharing initially during the downloading: 1500/3 = 500x1000kbps for a few seconds each = 50000 kilobits or 62.5MB. A worst-case spike scenario of all entering at once due to host error or a late upload due to last minute editing (this should be avoided if possible): 1500×1000=1500000 kilobits or187MB spike for up to 10 seconds depending on latency effects on the initial download. This spike may be missed in testing if you rely on the Meeting room bandwidth indicator as it may happen too fast to register; it is better measured using Wireshark on a client in the Meeting.

Case 2: A 1500 user seminar room with a PowerPoint and a 10 minute MP4 Video played:

Estimate: 1500 users x 50 kilobits each for the PPTX=75000 kilobits or 9MB. Assuming a medium quality MP4 (as discussed above) uploaded to the meeting room and meted out at an average 600 kbps per participant with intermittent spikes to 1200 kbps: 1500×1000=1500000 kilobits or187MB + 9 = 196MB while the video is being played with the PPTX still onstage visible in another pod. Note: Until the Video is played, this room is at 9MB just meting out PPTX SWFs after the initial SWF downloads are complete.

 Note: PPTX download spike variables as described in case # 1 above applies.

Case 3:  A 1500 user seminar room with a PowerPoint and two, 3 minute videos played:

Estimate: Same as case 2 above assuming that the videos are played one at a time.

Case 4: Two 1500 user seminars with just PPTs for content (uploaded to the Meeting room and not screen-sharing) and jpeg pictures for Presenter head-shots in lieu of a camera:

Estimate: 1500 users x 50 kilobits for the PPTX=75000 kilobits or 9MB x 2 seminar rooms = 18MB

 Note: Assuming the seminars will not start both at the same time and will nevertheless overlap, the brief PPTX download spike variables as described in case # 1 above applies albeit multiplied by two: 126 MB for 1/3^rd and worst case of both seminars doing a last minute deck upload at the start of the Meeting: 274MB until initial downloads complete. Staggering slightly the start of each seminar will mitigate the overall spike as will allowing users to trickle into a prepared room with assets on stage.

Case 5:  Two 1500 user seminars with just PPTs for content (uploaded to the Meeting room and not screen-sharing) and PPTs for headshots shared, PLUS 100 separate Connect meetings of 20 users each, with 10 of those meeting rooms sharing one web camera:

Estimate: 1500 users x 50 kilobits each for the PPTX=75000 kilobits or 9MB x 2 = 18MB, plus 90 meeting rooms with 20 users each doing the same activity, 1800×50 kilobits=90000 kilobits or 11MB, plus the 10 meetings with cameras added 10 x 20 users each x 200 kilobits=40000 kbps or 5MB; also add the upload for each camera 10 cameras x 200 kilobits =2000 kbps or .25MB. Total =.28000 kilobits or 35MB.

Note: Assuming the various meetings will be starting at different times the spike estimates for #4 above apply.

Case 6:  Two 1500 user seminars with just PPTs for content and PPTs for headshots shared, PLUS 100 separate Connect meetings of 20 users each, with 10 of those meeting rooms sharing one web camera, PLUS one 500 user seminar with a PowerPoint shared(uploaded to the Meeting room and not screen-sharing).

Estimate: Add 500 users x 50 kilobits each = 25000 kilobits or 4MB. Add this to use case 5 depicted above: 35MB+4=39MB.

Note: Assuming the various meetings will be starting at different times the spike estimates for use cases #4 and #5 above apply here.

Case 7: Two 1500 user seminars with just PPTs for content and PPTs for headshots shared,  PLUS 50 separate Connect meetings of 20 users each with 10 of those meeting rooms sharing one web camera, and one 500 seminar with just a PowerPoint shared (uploaded to Meeting room and not screen-sharing):

Estimate: 1500 users x 50 kilobits each  for the PPTX=75000 kilobits or 9MB x 2 = 18MB, plus 40 meeting without cameras x 20 users each=800x50kbps= 40000kbps or 5MB, add the 10 meetings with cameras 10 meetings x 20 users x 200 kilobits=40000 kbps or 5MB; also add the upload for each camera 10×200=2000 kbps or .25MB. Total= 232000 kilobits or 29MB.

 Note: Assuming the various meetings will be starting at different times the spike estimates for use case #4, #5 and #6 above apply.

Conclusion:

It is easy to avoid both overestimating and underestimating the bandwidth needed account-wide for Connect deployments on-premise or in the cloud. For large Webinars, a quick rehearsal with a small sample audience of external and internal users as appropriate is prudent. Best practices in large Meetings make a substantial difference in the amount of bandwidth utilized: Proper camera use, screen-sharing and video-encoding are all very important considerations.  Although it may at this point seem like a mantra, a basic best practice that so many Connect users miss is to upload a PowerPoint to the Meeting room share pod rather than use screen-sharing to run through a slide-deck. Maybe some Presenters are just overly possessive and have an innate refusal to let their work upload – whatever the reason, I will surely be in a Meeting today and some Presenter will share a PowerPoint from their desktop via screen-sharing and I will need to avert my eyes to maintain my light grasp on sanity. Used properly, Adobe Connect is the best means to deliver rich collaboration experiences while minimizing the impact on bandwidth utilization.