Вопрос: Каковы возможные недостатки для установки (очень) большого initcwnd для высокоскоростных соединений?


Я экспериментировал с параметрами TCP в Linux (с ядром 3.5). В основном касается этой связи:

Сервер: Gigabit uplink в центре обработки данных, фактическая пропускная способность (из-за совместного использования восходящих линий) составляет около 70 МБ / с при тестировании из другого центра обработки данных.

Клиент: Gigabit локальный LAN подключен к 200-миллиметровому волокну. Получение пробного файла на самом деле достигает 20 МБ / с.

Задержка: около 50 мс в оба конца.

Удаленный сервер используется в качестве файлового сервера для файлов в диапазоне от 10 до 100 МБ. Я заметил, что с использованием initcwnd из 10 время передачи для этих файлов сильно зависит от медленного запуска TCP, за 3,5 секунды для загрузки 10 МБ (максимальная скорость достигает: 3,3 МБ / с), поскольку она начинает медленно, а затем растет, заканчивается до достижения максимальной скорости. Моя цель - настроить минимальное время загрузки этих файлов (так что не самая высокая пропускная способность канала или низкая латентность в оба конца, я готов пожертвовать обоими, если это уменьшит фактическое время, необходимое для загрузки файла)

Поэтому я попробовал простой расчет, чтобы определить, какой должен быть идеальный initcwnd, игнорируя любые другие соединения и возможное влияние на других. Задержка-задержка составляет 200 Мбит / с * 50 мс = 10 Мбит или 1.310.720 байт. Учитывая, что initcwnd установлен в единицах MSS и предполагается, что MSS составляет около 1400 байт, для этого потребуется установка: 1.310.720 / 1400 = 936

Это значение очень далеки от стандартного (10 * MSS в Linux, 64 КБ в Windows), так что не хочется создавать его так. Каковы ожидаемые недостатки его настройки таким образом? Например:

  • Это повлияет на других пользователей той же сети?
  • Может ли это создать неприемлемую перегрузку для других соединений?
  • Flood-маршрутизаторы-буферы где-то на пути?
  • Повысить влияние небольших объемов потери пакетов?

8
2018-01-05 23:21


Источник


Можете ли вы подтвердить, что говорите мегабайт / с, когда говорите 70 MB/s а не мегабит? Просто ищите разъяснения. - Andy Shinn
Да, мегабайт / с не мегабит. - Tomas
Если бы я был вами, я бы попытался умножить его на 2 раза (10, 20, 40, 80, ...) и посмотреть, как он улучшает типичное время загрузки - mvp


Ответы:


Каковы ожидаемые недостатки его настройки таким образом? Например:

Will it affect other users of the same network?

Изменение initcwnd повлияет:

  • Пользователи сервера с изменениями настроек
  • ЕСЛИ эти пользователи соответствуют маршруту, на который настроено изменение.
Could it create unacceptable congestion for other connections?

Конечно.

Flood router-buffers somewhere on the path?

Не несущественны, но если они не являются вашими маршрутизаторами, я бы сосредоточился на вопросах, которые вам ближе.

Increase the impact of small amounts of packet-loss?

Конечно, он может это сделать.

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

Это также увеличит шансы на повторную передачу пакета этих пакетов, поскольку один из первых пакетов в пакете будет потерян.


1
2018-02-21 09:17



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


Я не думаю, что полностью понимаю, о чем вы просите, вот попытка ответить:

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

Изменение initcwnd на (например, 10) означает, что 10 пакетов сразу исчезнут. Если все они достигнут своей цели, вы можете получить гораздо большее окно в первом RTT из-за медленного запуска (экспоненциальное увеличение cwnd). Однако при потере пакетов cwnd будет сокращен вдвое, и поскольку вы будете разрывать 10 пакетов, у вас будет значительное количество повторных передач, чтобы у вас могло возникнуть больше проблем, чем вы думаете.

Если вы хотите попробовать что-то более агрессивное и быть каким-то «грубым» для других пользователей Интернета, то вместо этого вы можете изменить алгоритм управления перегрузками на стороне сервера. Различные алгоритмы обрабатывают cwnd по-другому. Имейте в виду, что это повлияет на всех пользователей, если ваше серверное программное обеспечение не изменит это для каждого соединения (что я очень сомневаюсь). Преимущество здесь в том, что алгоритм будет действовать даже после потери пакетов, в то время как initcwnd не будет играть большую роль.

/ proc / sys / net / ipv4 / tcp_congestion_control - это то, где вы меняете алгоритм управления перегрузками.

FWIW для таких небольших RTT (50 мс), а для средних или больших файлов initcwnd не должен сильно влиять на вашу среднюю скорость. Если нет потери пакетов, то (т. Е. Жирная труба) cwnd будет удваиваться при каждом RTT. С RTT = 50 мс на жирной трубе вы в первый раз поместите 20 RTT, а это означает, что с initcwnd = 2 вы получите cwnd = 2 * 2 ^ 20 через 1 секунду, и я ставлю больше, чем вы можете ручка ;-)


0
2018-05-03 18:09