Tim Greene over at Network World has just posted a great article titled The ABCs of WAN Optimization Savings. The article walks through the various functions of today's WAN optimization devices and how these technologies add up to big savings for IT. Citrix is singled out in the article for our dominance in speeding up virtual desktops and applications, something we have offered since delivering ICA acceleration with Branch Repeater 5 back in February.

As part of the HDX technology framework, Branch Repeater includes a suite of WAN optimization technologies that have been adapted for virtual environments. Since the underlying WAN optimization technologies are discussed in the Network World article, I will explain how Branch Repeater is unique in applying these to accelerate and optimize virtual desktops and applications.

Compression and caching - By default, XenApp compresses all ICA traffic to optimize individual user sessions. Branch Repeater automatically negotiates with XenApp to disable the native ICA compression in order to cache common graphics and data locally in the branch and compress traffic across multiple user sessions. Branch Repeater is the only WAN optimization solution that can inspect the ICA virtual channel to help determine whether to store cached data objects in memory or on disk. This helps to minimize latency for interactive traffic (screen updates, mouse movements) while maximizing compression ratios for bulk transfers within ICA (printing, file transfers).

TCP acceleration - Like any TCP-based traffic, ICA performance can suffer due to high latency and packet loss common on long distance WAN connections. Branch Repeater overcomes these issues with adaptive TCP flow control that senses these conditions and responds by optimizing TCP behavior.

QoS and traffic prioritization - In many networks, ICA shares the wire with other bandwidth hungry applications. Network congestion can 'starve out' ICA traffic causing slow and inconsistent performance. Branch Repeater prioritizes traffic and allocates bandwidth to ensure reliable, high-performance for virtual desktops and applications. However, not all data transmitted within ICA should receive equal priority. For instance, interactive screen data should be prioritized above print jobs. To address such conflicts, Branch Repeater provides the only ICA-aware QoS engine that can granularly allocate bandwidth based on virtual channel priority tags.

Branch Repeater ICA acceleration goes beyond optimizing each of these core technologies for virtual desktop and application delivery. Virtual environments tend to be far more dynamic and flexible than traditional enterprise applications. For this reason, Branch Repeater is fully integrated with XenApp and other HDX technologies to apply the right mix of optimizations for every scenario over any network. And since many of the techniques involve peering inside the ICA session, Branch Repeater works with native ICA encryption (Basic and Advanced RC-5) so there is no compromise to end-to-end security.

The Network World article wraps up by suggesting that businesses consider WAN optimization gear when deploying new applications. Rolling the cost of WAN optimization into a larger IT project - such as desktop virtualization - can be a cost-effective way to pay for the solution. So if you are considering deploying virtual desktops (VDI) in your organization, be sure to include Branch Repeater as part of your plans.

Take this quick survey to tell us more about the solutions your organization uses to optimize your WAN. 

HDX MediaStream does a fantastic job of reducing the network bandwidth requirements for streamed video compared with rending the video on the server. When using HDX MediaStream your bandwidth requirements roughly equal the bit rate of the source video file. For lower quality clips, like those found on YouTube, this is around 256Kbps. For full HD content the bandwidth requirements can be as high as 8Mbps.

While this works great over a high speed LAN, trying to push that amount of data over typical branch office T-1 is another story. This problem is magnified even more when you have multiple users in the branch office who are repeatedly pulling down the same video content. In this situation, the video quality suffers and other business applications can be impacted. This issue has nothing to do with XenApp or XenDesktop. It is purely a function of the size of video file and the limited amount of available network bandwidth.

What can you do about this? Well if the culprit is the latest viral video making its way around the Internet you could attempt to block access to sites like YouTube. However, what if the video is for legitimate business purposes? I talked to one customer at Synergy who is rolling out a corporate compliance training video to their entire company using XenApp but is worried about the impact to network bandwidth.

Enter Citrix Branch Repeater and HDX IntelliCache. With Branch Repeater 5 we now participate in the ICA session and accelerate the ICA virtual channel used by HDX MediaStream. The first time the video is streamed to the branch office, Branch Repeater caches the content locally. The next time the video is requested, Branch Repeater serves the content from its local cache rather than pulling it across the WAN. Using branch caching, you can reduce the bandwidth requirements for on-demand videos by up to 90%.

Don't just take my word for it. You can see a demo if this in action on the latest edition of Brian Madden TV. (If you don't want to watch the entire episode you can jump ahead to 5:49 into the clip).

Have you been hearing about the new Citrix HDX Technologies? Have you heard that HDX enables branch office users to get that "high definition" XenApp experience? Are you still trying to figure out what this all really means?

• What is driving branch offices to virtualize their applications
• What are branch offices doing about the WAN
• What Citrix Branch Repeater does for XenApp
• How HDX Broadcast and HDX IntelliCache deliver a high-def branch experience

The whitepaper (CTX120455) is available for download on the Branch Repeater section of the Citrix Knowledge Center.

Does your organization deliver virtual applications to the branch office over a sloooow WAN link?
Are you tired of trying to fix all of your WAN issues with a bigger and more expensive WAN connection?

There has to be a better solution...
Citrix Branch Repeater and XenApp work in concert to deliver a "high-definition" branch office experience, drastically improving the XenApp experience to branch office users. Using Citrix HDXTechnology, Branch Repeater and HDX IntelliCache adaptively orchestrate with XenApp to disable the native ICA compression used for optimizing single-user sessions.

Just how much better?

• Branch Repeater reduces XenApp traffic by up to 95 percent, increasing file transfer throughput by up to 20 times and increasing print traffic throughput by up to 33 times.
• Together these enhancements allow customers to serve up to 4x more XenApp users in each branch without upgrading bandwidth.

Learn more about ICA Optimization, how to deploy the components, and see the High Definition branch experience yourself in this exciting demo, which can also be found on the Branch Repeater demo page of Citrix.com.

На днях, во время встречи с одним из Заказчиков мне задали вопрос, начало которого было привычным, а вот продолжение - не совсем. Скажу сразу, меня поставили в тупик и я взял тайм-аут для размышлений.

Вопрос звучал так: "У нас есть канал с известными характеристиками, есть приложение, установленное как локально, так и опубликованное на сервере Citrix XenApp. Когда у пользователя на его локальном устройстве будет прорисован экран после запроса информации?"

Приложение транзакционное, соответственно время реакции локального приложения посчитать достаточно просто. Оно равно - количество транзакций * на задержку в канале передачи данных. Естественно здесь принимается допущение о том, что размер транзакции меньше размера сетевого пакета и временем отрисовки графической подсистемой можно пренебречь.

После обдумывания на досуге и совместного мозгового штурма с моим коллегой Николаем Шадриным, у нас получилась вот такая интересная формула:

Время вывода на экран локального устройства экранной формы опубликованного приложения = (Глубина цвета*Размер экрана по вертикали*Размер экрана по горизонтали * Степень сжатия * Процент новой информации)/8 *(Задержка в канале/Размер окна при сетевой передаче + 1/Ширина полосы пропускания)

А теперь попробуем пояснить, что есть что:

• Глубина цвета - измеряется в битах, является характеристикой экрана опубликованного приложения, обычно 8, 16 или 24.
• Размер экрана по вертикали - размер экрана отображаемого приложения в пикселях по вертикали.
• Размер экрана по горизонтали - размер экрана отображаемого приложения в пикселях по горизонтали.
• Степень сжатия - коэффициент, который введён, чтобы учитывать технологии сжатия, применяемые при передачи информации с помощью протокола ICA. Изменяется от 1 (никакого сжатия вообще), до 0 (недостижимый идеал сжатия). Мы для своих расчётов брали практический коэффициент - 0.1. Т.е. изначальная информация сжимается в 10 раз.
• Процент новой информации. Известно, что протокол ICA передаёт только изменившуюся информацию на экране, а не весь экран целиком.Так что коэффициент также меняется от 1 - абсолютно новая экранная форма, до 0 - никаких изменений на экране не происходило.
• Задержка в канале - сек, то время, которое необходимо пакету пройти от точки А в сети до точки Б и обратно.
• Ширина полосы пропускания - это скорость передачи в канале, измеряем в байтах в секунду.
• Размер окна при сетевой передачи - сетевой параметр TCP Window Size, определяющий количество принятых байт, до момента отправки подтверждения.

А теперь давайте рассмотрим это на примерах:

Наши исходные данные:
Размер экрана - 1024*768
Задержка в канале - 0.2 сек
Полоса пропускания - 6400 байт/сек, это приблизительно 50 кбит/сек
Глубина цвета - 24 (второй вариант - 8)
Степень сжатия - 0.1 (данные из практики)
Процент новой информации - 1 (для варианта 2 - 0.05 - это значит, что на экране обновилось 5% информации)
Размер сетевого пакета = 1460 байт (msdn.microsoft.com)
Размер окна = 17520 байт (msdn.microsoft.com)

В результате получаем следующие данные

Глубина цвета 24 и 100% новой информации:
Объём данных = 1024 * 768 * 24 * 0.1 * 1 / 8 = 235930 байт
Количество пакетов = 17520 / 1460 = 12
Время = (235930 * 0.2 / (12* 1460) + 235930/6400) = 39.56 сек

Глубина цвета - 8 бит и 100% новой информации:
Объём данных = 1024 * 768 * 8 * 0.1 * 1 / 8 =78643 байт
Количество пакетов = 17520 / 1460 = 12
Время = (78643 * 0.2 / (12* 1460) + 78643/6400) = 13.19 сек

Глубина цвета 24 и 5% новой информации:
Объём данных = 1024 * 768 * 24 * 0.1 * 0.05 / 8 = 11797 байт
Количество пакетов = 17520 / 1460 = 12
Время = (11797 * 0.2 / (12* 1460) + 11797/6400) = 1.98 сек

Глубина цвета - 8 бит и 5% новой информации:
Объём данных = 1024 * 768 * 8 * 0.1 * 0.05 / 8 =3932 байт
Количество пакетов = 17520 / 1460 = 12
Время = (3932 * 0.2 / (12* 1460) + 3932/6400) = 0.66 сек

Вот мы и получили, данные, на которые можно опираться при начальных расчётах. Конечно практика это критерий истинны, и поэтому я рекомендую проверять все такие выкладки на практических тестах.

Удачи.

P.S. Во вложении к этой статье находится Excel файл для расчётов.