Можно ли отклонить входящие пакеты UDP, когда нисходящий канал перегружен?

Question

Как я понимаю, исходящие пакеты любого транспортного протокола могут быть приоритетными, но для TCP, UDP и SCTP только TCP и SCTP имеют управление перегрузкой, позволяющее также приоритезировать их входящие пакеты.

UDP не контролирует перегрузку, поэтому нет способа сообщить исходной машине о входящих UDP-пакетах, чтобы они замедлили их отправку.

Поэтому мой вопрос: возможно ли обрезать UDP-соединения непосредственно перед тем, как они начнут влиять на качество высокоприоритетных соединений? Если да, то как лучше всего это настроить на OpenWrt?

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

Редактировать:

Контроль перегрузки SCTP и TCP, на который я ссылаюсь, называется явным уведомлением о перегрузке (ECN). С тех пор я понял, что вполне возможно, что приложение игнорирует или неправильно реализует поддержку ECN, поэтому я хотел бы распространить этот вопрос на все, что не отвечает на ECN, включая UDP. Поэтому, если мой маршрутизатор сообщает удаленному хосту «замедлиться» (через ECN), и этот хост продолжает пересылать слишком много данных моему провайдеру, я хочу отклонить всю входящую связь с этого хоста, которая, если это не DOS атака должна привести к ошибке ICMP «отказано в соединении» и разорвать соединение. Если этого недостаточно, то дополнительное отклонение исходящих пакетов на хост должно по крайней мере вызвать ошибку тайм-аута.

Answer 1

UDP не контролирует перегрузку, поэтому нет способа сообщить исходной машине о входящих UDP-пакетах, чтобы они замедлили их отправку.

На уровне UDP это правда.

Поэтому мой вопрос: возможно ли обрезать UDP-соединения непосредственно перед тем, как они начнут влиять на качество высокоприоритетных соединений?

Только ваш провайдер может это сделать. Когда пакет прибыл на ваш маршрутизатор, он уже привел к перегрузке, и UDP ничего не сообщает источнику, он полностью односторонний.

Как и в случае с OpenWRT, они объявляют об ограничении своих возможностей по формированию трафика:OpenWRT Traffic Control

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

Опять же, UDP не сообщает источнику, что пакет был отброшен. Он просто выбрасывает пакеты по вашей ссылке и не заботится о том, что залипает.

Если вы просто отбрасываете пакеты и надеетесь на лучшее:

Вам может повезти с протоколами, построенными на UDP. Потоковое видео, SIP-данные и т.д. Обычно используют UDP, но очень чувствительны к потере пакетов, обнаруживают их и "надеются" на возможность оптимизировать использование собственной полосы пропускания.

Точно так же вы можете испытать неудачу и инициировать повторную передачу пакетов, если протокол приложения обнаруживает потерю пакетов, но требует, чтобы эти пакеты были переданы (bittorrent), он мог бы перебрасывать пакеты несколько раз по вашему каналу и перегружать его еще больше.

Но есть способы получить контроль над тем, что идет по вашей ссылке: если вы не знаете своего провайдера достаточно хорошо, чтобы позволить вам разместить маршрутизатор, формирующий трафик, в их конце, вы можете арендовать сервер в инете с толстой ссылкой и сделайте это своим маршрутизатором / шлюзом, и реализуйте там формирование трафика. С Linux, есть множество способов добиться этого.