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

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

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

Клиент: локальная сеть Gigabit, подключенная к 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), поэтому не стоит устанавливать его так. Каковы ожидаемые недостатки его настройки? Например:

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

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

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 для любого, кто способен выполнить трехстороннее рукопожатие (значительные объемы данных для небольших инвестиций (объем данных) в).

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

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

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

Изменение 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 секунду, что, я уверен, больше, чем вы можете ручка ;-)