Запрос: Типы туннелей FEC

Интересная идея... Вижу, что туннелирование на базе FEC может помочь с LTE, где мало что можно “подкрутить” в сети, чтобы избежать потери пакетов, и FEC-туннелирование может сгладить потери пакетов, вызванные проблемами с RF-приёмом (но не проблемами с перегрузкой...). По сути, это будет «двойной FEC», так как слой LTE уже применил FEC к пакетам LTE перед их декапсуляцией в IP для Mikrotik. Но польза может быть ограниченной: чтобы FEC работал, потери пакетов на уровне 3 должны иметь относительно предсказуемую частоту, иначе всё равно будут потери либо неэффективно расходоваться пропускная способность на ненужные коды FEC. Кроме того, если потери пакетов связаны с перегрузкой, FEC может быть даже вреден по сравнению с другими методами.

Для проблем с качеством VoIP уже существует множество способов их решения (даже слишком много), и реализация туннелирования UDP с применением FEC не станет волшебной палочкой. Например, стоит убедиться, что RTCP используется в SIP и/или вашем медиасервере — это даёт обратную связь в реальном времени по RTP на основе реально условий сети, а не фиксированной скорости FEC. Не уверен, насколько это поддерживается в IP-АТС, но RFC 5109 описывает использование FEC непосредственно в потоке RTP (например, на уровне ISO Layer 4): https://tools.ietf.org/html/rfc5109 (а также в WebRTC, см. https://tools.ietf.org/html/draft-ietf-rtcweb-fec-07)...

Сейчас где FEC-туннель на базе UDP в Mikrotik действительно выглядит логичным — это возможность избежать повторной передачи TCP через нестабильную сеть (например, LTE), так как типичный механизм управления перегрузками в TCP предполагает, что потеря пакетов всегда связана с перегрузкой. Когда ошибки неизбежны и не связаны с перегрузкой, FEC действительно оправдан, но это не просто галочка в настройках EoIP-туннеля...

Я бы сказал, что использовать полноценный FEC, например reed-solomon, для этой задачи немного излишне, ведь можно ожидать, что вы получите либо правильные пакеты, либо ничего. Конечно, код reed-solomon мог бы исправить некоторые битые пакеты, но действительно ли они случаются на практике? Как было написано выше, этим уже занимаются более низкие уровни. Здесь больше подойдёт что-то вроде паритетной схемы, похожей на RAID-5.

Думаю, многие избегают запускать VoIP через туннелирование (потому что это добавляет новый уровень джиттера и задержек). Повторную передачу данных всегда нужно обрабатывать на уровне приложения, ведь только приложение знает, что именно нужно переслать. Но решение действительно классное.

Я не понимаю, почему такой узкий акцент на последней миле. БОЛЬШИНСТВО провайдеров проходят через 6-15 переходов на 3-5 разных операторах, чтобы добраться до удалённого ресурса. Так зачем заморачиваться, что в LTE есть встроенная коррекция ошибок, которая превращает потерю данных в задержку? Технология доставки никак не влияет на конечную цель. Нужно использовать сквозное FEC, чтобы уменьшить потерю пакетов и всплески задержек по всему пути. В LTE много встроенной задержки из-за ptmp-планирования (я ведь управляю LTE-точками доступа...), и когда происходит повторная передача, задержка резко возрастает. Эти системы настроены на передачу данных, а не на коммуникации в реальном времени. Если LTE восстанавливает пакет на канале и добавляет 80 мс задержки, для меня такой пакет можно считать потерянным.

Связанные вопросы: мне интересно, пробовал ли кто-то здесь использовать /ip packing для решения тех проблем, которые описывает @rOOt? Думал, что Mikrotik мог бы добавить FEC (например, reed-solomon или что-то похожее) в /ip packing… Лично я никогда не пользовался этой функцией (но теперь заинтересовался), и, кажется, это могло бы решить похожие задачи, что и tinyfecvpn. И, если подумать, поскольку /ip packing уже поддерживает сжатие заголовков IP (и тела?), это уменьшает количество бит, передаваемых по каналу, что могло бы компенсировать дополнительный трафик, связанный с контрольными битами FEC. Вики говорит, что /ip packing добавляет задержки… но, в общем, это та же цена, что и tinyfecvpn или UDPspeeder — обмен задержкой и пропускной способностью ради более стабильного потока данных на уровне L3. Но судя по малому количеству информации о /ip packing, похоже, что Mikrotik и другие по какой-то причине не слишком его жалуют?

Могу вас уверить (работал профессионально 15 лет инженером по радиосвязи в MNO, занимался проектированием сети и кучей устранения неполадок), что LTE обладает отличными механизмами доставки данных именно так, как нужно. Существует 3 разных режима (прозрачный, неподтверждённый и подтверждённый), которые используются для разных типов трафика (прозрачный — в основном для LTE-сигнализации, так что пользователям он не особо интересен; неподтверждённый — для разных реальных задач в реальном времени, например, VoLTE — это нативный VoIP в LTE), а для передачи данных используется подтверждённый режим. В нём реализованы все известные на момент создания LTE виды защиты данных, включая... вы не поверите... FEC. Это значит, что данные доставляются без ошибок в 99,999% случаев, но в крайних случаях может появиться небольшая задержка или вариация в задержке. Остальные 0,001% — это потеря пакетов. Но я бы не называл LTE особо «потерянным» по этому поводу. Несколько реальных данных по производительности FEC: допустимый битовый уровень ошибок на уровне RLC (его можно сравнить с уровнем MAC в WiFi) около 10% (зависит от настроек FEC, может быть и выше, но в хороших условиях это приводит к потере пропускной способности из-за добавленных данных FEC), и большая часть ошибок исправляется FEC. Оставшиеся необработанные ошибки ведут к ошибкам кадров, которые повторно передаются тем же уровнем RLC (механизм называется HARQ), что добавляет задержку около 5-10 мс. Есть ограничение на количество повторных передач, и если данные не проходят до достижения этого лимита — они теряются... но такое происходит очень редко и только при резком ухудшении радиосвязи (например, если устройство попадает в «радиотень» или появляется сильный источник помех), но практически не случается для стационарных соединений (то есть для фиксированного широкополосного доступа). LTE и WiFi принципиально отличаются по механизмам доставки данных...

Согласен с @mkx насчёт LTE — это реально надёжная штука, и полезность «двойного FEC» вполне можно ставить под сомнение. Если вы WISP, оператор или провайдер, который разворачивает сеть и хочет использовать FEC-туннель, то это просто сумасшествие. Не хочу снова придираться к LTE… Функция FEC может быть полезна, когда вы не контролируете каналы между сетевыми туннелями и не можете просто исправить какую-то проблему, из-за которой на уровне L3 теряются пакеты. Это может быть любой тип канала, хотя скорее всего — беспроводной. Но всё же считаю, что «кейc» @rOOt с живым видео, которое идёт через LTE чужой сети, — это то место, где FEC-туннель на Mikrotik может приносить пользу. Без сомнения, общий уровень потери пакетов на LTE низкий, но в плотной среде с большим количеством LTE-пользователей, например, в крытом спортивном комплексе, потери пакетов становятся больше, чем просто 0,001%. Потеря пакетов при UDP MPEG-TS стриме означает ухудшение качества изображения, и большинство видеооборудования не может просто взять и перейти на TCP. Несмотря на то, что FEC добавляет задержку и нагрузку, допустимые задержки при вещании видео изначально ориентированы на спутниковые каналы (около 500 мс) [а именно там FEC и применяется в DVB-S], так что если FEC-туннель поверх LTE добавляет, допустим, 50–100 мс задержки, но при этом снижает общие потери пакетов, это выигрыш, потому что у приёмника выше терпимость к задержкам, чем у LTE. Поэтому «подход с про запас» — добавлять дополнительный FEC (поверх встроенного FEC LTE) в сильно перегруженных LTE-средах — в целом имеет смысл... даже если это и не самое красивое решение.

Не говоря уже о том, что LTE предлагает довольно качественный набор QoS, и можно попытаться получить более высокий уровень качества обслуживания у своего мобильного оператора. Оператор, в котором я работал, предлагает IPTV через LTE (это, кстати, TCP-сервис), но он использует другой профиль QoS по сравнению с обычным дата-сервисом, так что в случае перегруженных LTE ячеек у него приоритет над остальными данными. Это значит, что клиенты не видят страшные сообщения «буферизация», которые иногда всё же возникают. Правда, с помощью механизмов QoS ничего не поделать с плохим радиосигналом (IT-шники, конечно, этого хотели бы)… Мы также сталкивались со множеством «необычных» запросов от некоторых клиентов (например, радиостанций и телеканалов).

Вижу два действительно хороших и интересных сценария использования: VOIP через сложные каналы связи. Например, когда едешь в машине по загородной местности, где LTE может быть недоступен и связь переходит на 3G или GSM. Это проблема даже для VoLTE и обычных переключений сотовой связи. Но может быть и проще — попытаться использовать VOIP в переполненном отеле через публичный Wi-Fi. Потери пакетов там ужасные, а если добавить ещё и VPN — вообще беда с пропусками… С FEC можно немного пожертвовать задержкой ради идеальной передачи. Настроить, например, на 100 мс задержки и большой избыточности, чтобы все потерянные или запоздавшие пакеты восстанавливались из оставшихся данных. Это работает очень хорошо, и небольшая задержка того стоит ради общего повышения качества. Видеотрансляции. Это не такое уж нишевое применение, как кажется. Люди любят стримить разные события на YouTube — конференции, школьные или корпоративные мероприятия. Тут не обязательно дорогое кинооборудование — можно приблизиться к кинематографичному качеству, имея оборудование за $5000. Но чаще всего «узким местом» становится именно канал загрузки. Профессиональные решения используют несколько LTE-модемов параллельно с FEC для надёжности. А с FEC-туннелем можно легко объединять несколько соединений одновременно для плавных переключений и стабильности. Можно собрать настройку, которая ни в чём не уступит дорогому профессиональному решению — роутер на OpenWRT, LTE-модемы с безлимитными тарифами и немного опыта. И вот дроны и БПЛА — рынок растёт как на дрожжах, а прямая трансляция видео остаётся одной из главных проблем. Mikrotik мог бы здесь серьёзно расширить присутствие, потому что текущие решения часто сильно ограничены по пропускной способности (видео ужасно сжато) или же радиус действия очень мал. А людям хочется стримить 4K-стереоскопическое видео в 60fps или сразу несколько видеопотоков (широкоугольную камеру, зум, тепловизор и т.д.). Идеальное применение для 60GHz-связи, если переключения будут достаточно надёжными и быстрыми, возможно с 5GHz в качестве резервного или для дальних дистанций. Вот тут FEC-туннель мог бы реально помочь. А ещё он полезен для диверситета сигнала (несколько приёмников на земле, например секторные антенны) и избыточности (резервное радио с плавным переключением). Показать такую систему в прочном исполнении на одной из военных выставок — это почти гарантирует реакцию «замолчите, возьмите мои деньги», независимо от цены… Сейчас ничего похожего на рынке просто нет.