Медийная индустрия давно знает и использует Aspera. В знак признания компания получила статуэтку Эмми на 65 церемонии вручении наград в номинации «an industry game changer»
Да, это правда, что в последнее время было разработано большое число высокоскоростных версий TCP протокола и апплайнсов которые поддерживали эти модификации. Новые версии TCP протокола признают фундаментальные недостатки AIMD алгоритма и уходят от механизма контроля перегрузки на основе окна TCP, дабы избежать искусственного ограничения скорости, вызванного им же самим и улучшить пропускную способность на больших расстояниях. Наиболее продвинутые версии протокола TCP стараются улучшить механизм обнаружения перегрузки, используя так же, как и FASP задержку нахождения в очереди, что лучше чем повышать скорость до тех пор, пока не случится потеря пакета. Это позволяет TCP не генерировать самому потери пакетов и тем самым, не включать искусственный механизм избежания перегрузки, это улучшает скорость передачи на сетях без потерь пакетов или с малым количеством потерь.
Однако, эти улучшения быстро исчезают в WAN сети, где потеря пакета может произойти из-за “физики” или переполнения буфера в результате всплеска трафика. Единичная потеря пакета на таких сетях, значительно уменьшит окно TCP, а если потерь будет много, то влияние на скорость будет катастрофическое.
Пропускная способность “быстрого” TCP (CUBIC, H-TCP, BIC и т.д.) будет больше стандартного TCP Reno на сетях с низкой задержкой, но это преимущество резко исчезает с ростом RTT. С ростом числа потерянных пакетов “быстрый” TCP сравняется по скорости с TCP Reno. В FASP пропускная способность не уменьшается с ростом задержки, с ростом потерянных пакетов пропускная способность FASP уменьшится на тоже самое число, пример 95% при 5% потери пакетов.
Реакция стандартного и “скоростного” TCP на потерю пакета заставит отправителя, не только уменьшить окно TCP, а также отправлять новые пакеты в окне с уже переданными ранее пакетами для того, чтобы поддерживалась TCP in-order delivery, т.е. доставка пакетов в том порядке в котором они были высланы. Понятно, что не всем приложениям нужна доставка пакетов по порядку, для передачи файлов она не нужна, в отличие например от стриминга видео.
Приведу пример калькуляции потери пропускной способности из-за единичной потери пакета в “скоростном” TCP с уменьшением окна TCP одна восьмая для каждой потери. Для Гигабитной сети с 1% потерей пакетов и 100 мс RTT, каждый потерянный пакет вызовет уменьшение скорости в одну восьмую (1/2 в TCP Reno), получится
1 Гбит/c ÷ 8 (бит/байт) ÷ 1024 (байтов/пакет) * 100 мс * 0,125 (уменьшение скорости/потеря) * 100 мс ~ 152.6 секунд потребуется отправителю для того, чтобы вернуться на прежний уровень передачи в 1 Гбит/c. В течение этого периода “скоростной” TCP потеряет 152.6 * 1 Гбит/c * 0.125/2 ~ 8.9 Гбайт пропускной способности из-за единичной потери пакета.
Однако, эти улучшения быстро исчезают в WAN сети, где потеря пакета может произойти из-за “физики” или переполнения буфера в результате всплеска трафика. Единичная потеря пакета на таких сетях, значительно уменьшит окно TCP, а если потерь будет много, то влияние на скорость будет катастрофическое.
Пропускная способность “быстрого” TCP (CUBIC, H-TCP, BIC и т.д.) будет больше стандартного TCP Reno на сетях с низкой задержкой, но это преимущество резко исчезает с ростом RTT. С ростом числа потерянных пакетов “быстрый” TCP сравняется по скорости с TCP Reno. В FASP пропускная способность не уменьшается с ростом задержки, с ростом потерянных пакетов пропускная способность FASP уменьшится на тоже самое число, пример 95% при 5% потери пакетов.
Реакция стандартного и “скоростного” TCP на потерю пакета заставит отправителя, не только уменьшить окно TCP, а также отправлять новые пакеты в окне с уже переданными ранее пакетами для того, чтобы поддерживалась TCP in-order delivery, т.е. доставка пакетов в том порядке в котором они были высланы. Понятно, что не всем приложениям нужна доставка пакетов по порядку, для передачи файлов она не нужна, в отличие например от стриминга видео.
Приведу пример калькуляции потери пропускной способности из-за единичной потери пакета в “скоростном” TCP с уменьшением окна TCP одна восьмая для каждой потери. Для Гигабитной сети с 1% потерей пакетов и 100 мс RTT, каждый потерянный пакет вызовет уменьшение скорости в одну восьмую (1/2 в TCP Reno), получится
1 Гбит/c ÷ 8 (бит/байт) ÷ 1024 (байтов/пакет) * 100 мс * 0,125 (уменьшение скорости/потеря) * 100 мс ~ 152.6 секунд потребуется отправителю для того, чтобы вернуться на прежний уровень передачи в 1 Гбит/c. В течение этого периода “скоростной” TCP потеряет 152.6 * 1 Гбит/c * 0.125/2 ~ 8.9 Гбайт пропускной способности из-за единичной потери пакета.