Как ограничить скорость загрузки при полном использовании скачивания?

Я бы сказал, что ваш единственный шанс — использовать глобальную очередь как родительскую, как вы и делаете, создать дочернюю очередь от global с установленными limit и max-limit, равными сумме скоростей загрузки и выгрузки, предоставленных вашим провайдером. Внутри неё сделать две дочерние очереди — одну для загрузки, другую для выгрузки, при этом очередь загрузки должна иметь более высокий приоритет (меньшее число), чем очередь выгрузки. То есть примерно так:

/ip firewall address-list add list=rfc1918 address=10.0.0.0/8  
add list=rfc1918 address=172.16.0.0/12  
add list=rfc1918 address=192.168.0.0/16  

/queue tree add limit-at=50M max-limit=50M name=common parent=global queue=default  
add limit-at=49M max-limit=50M name=download packet-mark=download parent=common priority=1 queue=default  
add limit-at=1M max-limit=50M name=upload packet-mark=upload parent=common priority=2 queue=default  

/ip firewall mangle  
add chain=prerouting in-interface=your-wan-interface-name action=mark-packet new-packet-mark=download  
add chain=prerouting dst-address-list=!rfc1918 action=mark-packet new-packet-mark=upload  

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

Ну, во‑первых, если ты создашь Download и Upload как прямые потомки global, без общего родительского очереди с лимитом между ними и global, ты потеряешь возможность ограничивать upload через download, потому что они не будут делить общий лимит этой родительской очереди. Моя изначальная иллюстрация в итоге как-то работала даже без указания приоритета, потому что сумма лимитов upload и download равна лимиту их общего родителя, и всего две дочерние очереди делят эту пропускную способность, так что приоритет абсолютный — когда одна очередь (upload) уже достигла своего предела, пакет из другой очереди предпочтительнее, если её скорость всё ещё ниже лимита, и при этом обе очереди ждут отправки пакета. Но это был (слишком) упрощённый пример; если дочерних очередей у одного родителя больше двух, скорость нескольких из них может не достигать своих лимитов, и тогда приоритет уже решает. И среди upload-пакетов нужно отдавать предпочтение тем, что подтверждают приём download-пакетов, иначе ты замедлишь загрузку и, что хуже, вызовешь повторную передачу download-пакетов. Значит, нужно больше двух приоритетов, и приоритеты работают только для очередей, которые не являются родительскими, то есть у которых нет дочерних очередей. С другой стороны, в такой необычной схеме можно назначить upload-пакетам только с ACK, которые подтверждают приём download-пакетов, тот же пакет-маркер, что и у настоящих download-пакетов, чтобы они использовали квоту загрузки общего родителя. В таком случае приоритеты не нужны для выбора между “загрузкой и связанной с ней” и “отдачей и связанной с ней” трафиком — и можно создавать дочерние очереди в обеих. В инструкции сказано, что приоритет решает между дочерними очередями; там правда явно не уточнено “одного и того же родителя”. Так что у тебя есть простор для собственных экспериментов.

Кажется, я наконец-то справился!  
/ip firewall mangle add action=mark-packet chain=prerouting new-packet-mark=important_traffic protocol=udp port=37,53,67,68  
add action=mark-packet chain=prerouting new-packet-mark=important_traffic protocol=tcp port=21,25,53,80,110,443,465,995,3389,8080  
add action=mark-packet chain=forward in-interface=all-ppp new-packet-mark=important_dl packet-mark=important_traffic  
add action=mark-packet chain=forward in-interface=!all-ppp new-packet-mark=important_ul packet-mark=important_traffic  
add action=mark-packet chain=forward in-interface=all-ppp new-packet-mark=torrent_dl packet-mark=no-mark  
add action=mark-packet chain=forward in-interface=!all-ppp new-packet-mark=torrent_ul packet-mark=no-mark  

/queue tree  
add limit-at=50M max-limit=50M name=QoS parent=global queue=default  
add limit-at=50M max-limit=50M name=1-web-down packet-mark=important_dl parent=QoS priority=1 queue=default  
add limit-at=50M max-limit=50M name=2-web-up packet-mark=important_ul parent=QoS priority=2 queue=default  
add limit-at=50M max-limit=50M name=4-etc-down packet-mark=torrent_dl parent=QoS priority=4 queue=default  
add name=8-etc-up packet-mark=torrent_ul parent=QoS queue=default  

Не уверен, влияет ли в этом случае использование chain=forward или prerouting, но для начала я отделяю нужный трафик от прочего по портам. Потом разделяю загрузку и отдачу (направление пакетов в /, не в ppp). Создаю родительскую очередь с установленными limit-at и max-limit, как советовали, чтобы задать лимиты всем дочерним очередям, кроме самой низкоприоритетной. В итоге у меня получается 4 дочерние очереди: для важной загрузки и отдачи (выбранные порты, приоритеты 1 и 2), и так далее для всего остального трафика (все немаркированные пакеты с приоритетом 4 для загрузки и 8 для отдачи).  

Для домашнего использования это, честно говоря, не так уж и нужно — можно просто выставить лимиты в торрент-клиенте. Также не до конца уверен по цифрам для полного дуплекса.  

Вот как это работает на практике, судя по моим наблюдениям: при загрузке торрентов на 50M (максимум моей полудуплексной полосы), как только я запускаю скачивание торрентов, без очередей отдача начинает перекрывать загрузку. Сейчас же загрузка почти достигает максималки, а отдача сильно снижается. Потом я начинаю скачивать через браузер — он идет на максимальной скорости, а торрент отстает.

Это не так — правила в цепочке prerouting обрабатывают как трафик от внешнего хоста к собственным адресам роутера, так и трафик, который роутер должен переслать от одного внешнего хоста к другому. Цепочки input и forward занимаются именно первым и вторым случаями соответственно.

В этом весь смысл — линия не симметрична 50/50. Как пишет автор, на этой конкретной линии 50 Мбит/с — это сумма загрузки и отдачи, потому что линия полудуплексная. И цель в том, чтобы торрент-загрузка имела низкий приоритет, уступая дорогу обычному «человеческому» веб-серфингу, когда это необходимо, поэтому трафик на скачивание должен быть в приоритете. И, как я уже не раз говорил выше, важно различать пакеты в направлении отдачи, которые подтверждают получение пакетов с загрузкой (инициированных человеком), и пакеты отдачи, которые несут полезную нагрузку (отдача торрента). Мы не выбирали интерфейс, а глобальную — это не интерфейс, а виртуальный объект, не связанный с каким-либо интерфейсом. Так что можно создавать сколько угодно дочерних очередей, настраивать для каждой лимит и максимальный лимит, как угодно. Это не меняет того факта, что ограничивать скачивание можно только замедляя доставку трафика в сторону LAN, поэтому если приложение-отправитель не получает обратной связи, ограничение не работает. Но если доля такого трафика не слишком велика, это особо не влияет на итоговый результат.

Ну, «загрузка» (download) и «отправка» (upload) — это не роли интерфейсов, а направления потока трафика через uplink, если смотреть с точки зрения клиентов LAN. Так что, если у вас несколько uplink’ов и несколько локальных LAN, у вас получается несколько интерфейсов, у которых исходящий трафик считается «отправкой» (WAN интерфейсы), и несколько интерфейсов, у которых исходящий трафик считается «загрузкой» (LAN интерфейсы). Очереди в RouterOS ограничивают только исходящий трафик, поэтому ограничение направления «загрузки» сводится к замедлению доставки пакетов, полученных через WAN, при отправке их клиентам через LAN интерфейсы. Это работает только если отправители получают обратную связь от получателей. Если отправители не сбрасывают скоростной режим и продолжают слать с той же скоростью, то просто сбрасывать уже полученные пакеты вместо доставки их LAN-клиентам не влияет на занимаемую пропускную способность в направлении загрузки. Хотя часто полезно использовать интерфейс как родителя очереди, потому что «корневой родитель» — это один из ключей для выбора очереди (второй — это packet-mark), если нужно ограничить направление загрузки целиком и у вас несколько LAN интерфейсов, придется использовать глобальный родитель и назначать разные значения packet-mark для пакетов в направлении отправки и загрузки.