Breeze Article

Introduction

When accelerated through a high-end Secure Socket Layer (SSL) accelerator such as F5 BIG-IP or Cisco Content Services Switch (CSS), the Breeze Meeting Secured Real Time Messaging Protocol (RTMPS) may uncover latency in networks where it was previously undetected.  RTMPS is not slow when it is accelerated through a high-end appliance, but it will most likely be the protocol which finds bottlenecks on a network. Here are three recent Breeze support case examples arranged in order of troubleshooting complexity that prove this point:

1. Example 1: A licensed Breeze Meeting server was directly hooked into an SSL accelerator; the relevant network interface card (NIC) on each device was set to auto-negotiate; the site experienced intermittent excessive Meeting latency. By setting both the SSL accelerator and the switch to 100 full duplex and connecting those via a crossover cable, latency diminished.
2. Example 2: SSL was terminated at a hardware-based load-balancing device (HLD). The HLD was connected to an end of life (EOL) switch. Latency was excessive. When we bypassed the switch, latency diminished.
3. Example 3: SSL was terminated at high-end HLD. Latency was significant; to diagnose the issue, we sniffed the clients, servers and the HLD while beginning RTMPS sessions and generating RTMPS traffic from the clients, across the network, through the HLD and onto the servers. After discovering that the source of the latency was somewhere between the clients and the Virtual Internet Protocol (VIP) address on the HLD, we narrowed our search to a problematic EOL switch. After replacing the EOL switch the Breeze Meeting experience was excellent and overall network performance improved for everyone, including those not using Breeze.

If in lab test environments there are problematic network devices and configurations causing latency, it is safe to assume that in any vast production network there will be ample opportunities for link-speed mismatches, faulty ports, bad cables, duplex mismatches, and so on. Any accelerated RTMPS performance problems are likely exacerbated by these previously hidden bottlenecks.

This article serves as a troubleshooting guide for network latency as it affects accelerated RTMPS. If you follow the guidance in this article you will not only diminish latency caused by accelerated RTMPS, but (depending upon the source of the latency) you may well find that overall performance in your network infrastructure will improve.

If there is a source of excessive latency in the network that is uncovered by accelerated RTMPS, then it will be obvious based on the experience in the Meeting. If you play an FLV file in the room, the end-user experience may be choppy. Along with this, if you pan the room with a camera, the experience in the Camera & Voice pod may appear  to be similar to that of a slide show rather than a seamless panorama. Screen sharing will be affected as it is a bandwidth-intensive exercise of accelerated RTMPS.

Section 1 of this article provides a brief description of a Breeze server pool behind an HLD/SSL accelerator and discusses techniques to isolate and fix sources of latency that affect accelerated RTMPS. Section 2 describes the bandwidth management tools available in the Breeze meeting room and recommends techniques to optimize the Meeting experience.

Requirements

• Software needed: Breeze Meeting, Updated versions of Internetwork Operating Systems (IOS), network diagnostic tools such as Ethereal or TCPDUMP, Breeze Meeting latency diagnosis software: Contest.
• Prerequisite knowledge: Basic networking skills, Familiarity with the TCPIP stack, understanding of DNS name resolution

Page 1 of 3

Next Page

About the author