QoS с переменной пропускной способностью.

Это не ограничение MikroTik, это просто как устроена сеть. Нужно делать QoS в самом узком месте канала. Когда у вас роутер подключён к модему с переменной скоростью, а соединение между роутером и модемом фиксированной скорости (например, Ethernet), то узкое место — это модем, и роутер тут бессилен. QoS должен делать модем. Можно, пожалуй, помочь ему, используя DSCP-манглинг или даже тег VLAN, который указывает приоритет (с помощью манглинга), но в конце концов приоритезацию очередей должен выполнять модем. Только если у вас фиксированная скорость соединения, можно «хитрить», используя очереди в роутере и задавая чуть меньшую максимальную скорость, чем фактическая. Тогда очереди модема остаются пустыми, и правильный QoS делается уже в роутере.

Настоящее качество обслуживания (QoS) можно обеспечить только на стороне передачи. Вы регулируете свои 2 Мбит вверх, а провайдер должен управлять QoS у себя. К сожалению, большинство из них не готовы правильно настроить своё оборудование, и вот у вас проблема. Когда мой провайдер пару лет назад поменял роутеры, ситуация резко улучшилась. Теперь они используют Fair Queue и, возможно, даже какое-то управление DSCP (точно не уверен), и теперь проблем с VoIP и скачиванием одновременно просто нет.

Похоже, в этой теме случилось недопонимание, и, возможно, именно это ты не совсем понял. Очередь нужно формировать на стороне, где генерируется трафик. То есть, когда смотришь IPTV и одновременно скачиваешь, это происходит у провайдера.

Если IPTV и интернет у тебя от одной компании, попроси их улучшить продукт, установив приоритет у IPTV-трафика выше, чем у интернет-трафика. Если же это разные компании, то, конечно, всё становится намного сложнее. Управление трафиком, которое ты делаешь на стороне приёма (или при передаче в локальной сети), никогда не будет работать так эффективно, как если это сделает провайдер.

Это, разумеется, особенно важно для соединений с переменным тарифом, но касается и фиксированных тарифов.

Можно, но тогда нужно как-то это контролировать! Теоретически можно написать скрипт, который будет менять параметры вашей очереди, но как вы узнаете, что именно нужно установить? Плюс, ограничение трафика на вашем конце напрямую не повлияет на то, что посылает другая сторона, а именно это вас и подводит. Я смотрел презентацию MUM 2016 по QoS, там тоже упоминали, что проблема в отсутствии абсолютного порядка пакетов по приоритету. В вашем случае это неактуально, потому что это должно применяться у провайдера, а не у вас дома. А у вашего провайдера, скорее всего, оборудование от другого производителя. Возможно, оно умеет делать то, что нужно, но вашему провайдеру лень открывать инструкцию и настраивать это, ведь деньги-то они всё равно получают. Они рекомендуют периодически запускать проверку скорости через скрипт, а затем записывать эти значения скорости загрузки и отдачи в очередь как limit-max — тоже с помощью скрипта. Похоже, это пока единственное решение. Лично я бы вместо теста скорости пытался мониторить IPTV-поток (поток непрерывный или подтормаживает?), или настроил бы пинг до IPTV-сервера и смотрел задержку (RTT). На основе этого уже попробовал бы регулировать настройки очереди — медленно увеличивать, когда всё в порядке, и быстро снижать при признаках перегрузки. Может, сработает. Но вряд ли всё это легко реализовать в скрипте MikroTik — скорее понадобится, например, Raspberry Pi с умной программой, которая будет управлять MikroTik через API.