Почему Jumbo Frames повреждают латентность?

Question

Недавно я читал о гигантских кадрах, и я запутался в нескольких местах. Насколько я понимаю, существует нижний предел размера кадра Ethernet между точками «сохранения» и «пересылки» (мосты уровня 2), поскольку кадры должны все еще передаваться, пока он достигает пункта назначения, чтобы включить обнаружение коллизий. Этот предел не затрагивается настройкой большого кадра.

Jumbo-кадры увеличивают верхнюю границу размеров фреймов с 1500B + заголовков до больших значений (например, 4000B или 9000B + заголовков).

Большие кадры позволяют снизить накладные расходы и т.д., Но есть больше шансов, что один пакет будет поврежден при передаче за пределы возможностей исправления ошибок. Если пакет поврежден, его необходимо повторно (целое) добавить к задержке. Кроме того, передача пакета занимает больше времени, так как он должен быть (как я полагаю) получен полностью перед передачей в CPU или пересылкой. Однако приложения, чувствительные к задержке, обычно используют UDP и нестандартные размеры пакетов, поэтому они не будут использовать гигантские кадры (если они не выполняют обнаружение MTU), поэтому на них не должны влиять гигантские кадры, так как кадры будут только короче.

Учитывая то, что я читаю гигантские кадры, измеримые задержки в измеримой степени, я начал задаваться вопросом, что вызывает этот эффект?

Answer 1

Вот несколько способов, которыми гигантские кадры могут повредить задержку. Вы уже знали некоторые из них:

1. Гигантский кадр 9 КБ в 6 раз больше, чем самый большой стандартный кадр Ethernet, который составляет 1500 байт. Таким образом, при той же частоте появления ошибок по битам у гигантских кадров вероятность появления ошибки в 6 раз выше, а когда возникает ошибка, весь 6-кратный кадр большего размера должен быть передан повторно.

2. Полином, который был выбран для алгоритма CRC32 в последовательности проверки кадра Ethernet (FCS), настроен для размеров кадра до 1500 байт. Это менее эффективно для больших размеров кадра, но гигантские кадры люди не меняли полином. Таким образом, битовые ошибки в больших кадрах с большей вероятностью останутся незамеченными на уровне MAC и должны быть обнаружены позднее на более высоком уровне (вероятно, на уровне приложений в случае UDP/IP), что приводит к еще большей задержке перед повторной передачей запрашивается.

3. Если пакет, чувствительный к задержке, оказывается в очереди за полноразмерным кадром для доступа к носителю, то на получение носителя требуется в 6 раз больше времени, если этот полноразмерный кадр представляет собой гигантский кадр 9 КБ, а не стандартный 1500-байтовый кадр. Рамка.

4. Если протокол, чувствительный к задержке, использует гигантские кадры и пытается заполнить их для эффективности использования полосы пропускания, доставка первых байтов кадра будет сильно задерживаться при ожидании создания последних байтов кадра до того, как кадр может быть заполнен. отправлено на провод. Для, возможно, наихудшего примера, некоторые высокопроизводительные голосовые кодеки могут использовать битрейт 2 Кбит / с, поэтому один кадр 9 Кбайт может составлять около 36 секунд речи. Представьте, что у вас 36 секунд задержки в вызове VoIP, потому что это. Конечно, как вы заметили, было бы так глупо разрабатывать протокол, чувствительный к задержке, что это кажется слишком очевидным, чтобы упоминать. Тем не менее, это все еще способ, которым использование гигантских кадров может повредить задержку.

Также обратите внимание, что Path MTU Discovery - это вещь IP-уровня, поэтому она не привязана к TCP. Таким образом, протоколы на основе UDP могут "извлечь выгоду" из Path MTU Discovery. Также обратите внимание, что вам не нужно делать PMTUD, чтобы узнать MTU локальной линии связи, поэтому, если ваш отправляющий хост находится в гигантском фрейме Ethernet, его MTU будет установлен на (до) 9000 байт даже без выполнения PMTUD , Что-то в том, как вы написали свой Вопрос, заставило меня подумать, что вы, возможно, этого не знаете.

PS Да, кадры должны быть получены полностью перед дальнейшей обработкой, потому что FCS приходит в конце и рассчитывается по всему кадру. Кроме того, в Ethernet нет исправления ошибок , только обнаружение.

Answer 2

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