Как TCP работает с тайм-аутами с cwnd? - PullRequest
3 голосов
/ 11 февраля 2009

Я недавно исследовал контроль перегрузки TCP, но меня мучает один вопрос ...

Если я все правильно понимаю, TCP не будет отправлять НОВЫЕ данные, если это не разрешено cwnd (окно перегрузки) и rwnd (окно принимающей стороны). Другими словами:

if(flightSize < MIN(cwnd, rwnd))
{
    // Send some new data (if possible)
    // Taking into account other details that we don't need
    // to get into such as Nagle's algorithm, etc.
}

Где flightSize - количество данных, которые были отправлены, но еще не подтверждены.

Предположим, что TCP работает, отправляя данные и увеличивая cwnd по мере необходимости. Допустим, cwnd = [10 полных пакетов] и flightSize == cwnd. Затем в сети происходит потеря пакета, и таймер повторной передачи отправителя отключается. Как / Когда New Reno ретранслирует неподтвержденные данные?

Вот мое текущее понимание / недопонимание:

Когда таймер отключается, cwnd будет сброшен на [1 полный пакет], самый старый отправленный, но неподтвержденный пакет будет повторно отправлен, rto будет удвоен, и таймер повторной передачи будет сброшен. Поэтому, если мы скажем, что rto было 1 секунда, когда таймер отключился, он будет обновлен до 2 секунд, и таймер повторной передачи снова запустится со временем ожидания 2 секунды.

Вот почему я запутался:

В описанной выше ситуации TCP отправит только один пакет. Даже если этот пакет получает ACK сразу, TCP не может отправить НОВЫЕ данные, потому что cwnd по-прежнему меньше, чем flightSize. Так что же это делает? Сядьте и подождите, пока 2-секундный таймер повторной передачи снова не сработает, прежде чем отправлять другой пакет? Вызывает ли это повторную отправку старых данных, поскольку не может отправить новые данные? Сбрасывает ли FlightSize и пересматривает ли все ранее отправленные данные для отправки?

Я прочитал все RFC, которые смог найти, и всевозможные руководства и пояснения по TCP. Должно быть, я что-то пропустил где-то ...


Разъяснение: Я рассматривал множественные потери, когда TCP не использует SACK.

Если получены дубликаты подтверждения, TCP отправит самый старый подтверждение 3-го дублирования подтверждения (быстрая повторная передача) и отправит новые данные после 4-го дублирования подтверждения (быстрое восстановление). Мой вопрос касается того, что произойдет, если отправитель TCP получит менее 3-х дублирующих подтверждений?

Ответы [ 2 ]

3 голосов
/ 12 февраля 2009

Я нашел ответ в книге "Иллюстрированный TCP / IP, том 2", раздел 25.11, страницы 842-844:

[По таймауту повторной передачи] следующий порядковый номер отправки (snd_nxt) установлен к самой старой неподтвержденной последовательности номер (snd_una). ... двигаясь snd_nxt назад, [TCP может начать повторно передать все неподтвержденные данные].

Другими словами, flightSize будет сброшен, поэтому данные можно продолжать отправлять (в режиме медленного запуска). Просто некоторые из этих данных могут быть данными, которые уже были отправлены ранее. Может появиться кумулятивное подтверждение, которое предотвращает повторную отправку всех данных.

0 голосов
/ 11 февраля 2009

Запрос на уточнение: рассматриваете ли вы потерю одного пакета? Или множественные потери в окне?

В случае единственной потери будут получены дублированные подтверждения из-за пакетов, полученных после потерянного. Я полагаю, что New Reno будет передавать последующие пакеты («НОВЫЕ данные») в ответ на дубликаты подтверждений. Затем он сбрасывает таймер тайм-аута.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...