Модели ТСР

Сентябрь 2, 2022

Главная
Алгебра
Модели ТСР

Содержание

2. 1. Вероятность ошибки доставки (BER) невелика и потеря пакета вероятнее всего происходит из-за переполнения буфера. Если
3. 5. Длительность TCP-сессии больше нескольких RTT, чтобы оправдать используемую протокольную избыточность. Короткие ТСР-сессии, широко используемые WEB-технологией
4. Трудности в реализации модели протокола ТСР возникли при работе с современными быстрыми (1-10 Гбит/с) и длинными
5. TCP-reno cwnd(t)=1; ssth(t)=(cwnd(t))/2; В настоящее время наиболее популярной является модель NewReno, изложенная в документе RFC-3782 (апрель
6. TCP Vegas
7. TCP-Tahoe
8. Сравнение функций отклика для разных протоколов
9. Алгоритм TCP HYBLA Основной идеей TCP Hybla является достижение для соединений с большим (напр. спутниковых) тех
10. Несовершенство версии протокола TCP Newreno для каналов с разными значениями RTT
11. CUBIC
12. Рост окна в модели CUBIC осуществляется в соответствии с выражением: W(t) = C(t-K)3 + Wmax где
13. Two CUBIC flows with 246ms RTT
14. Работа протокола TCP AIMD Additive-Increase, Multiplicative-Decrease (Область линейного увеличения CWND) Работа протокола TCP AIMD в режиме
15. Взаимодействие с чужими потоками При получении трех дублированных подтверждений (DUPACK) отправитель считает пакет потерянным и посылает
16. NTCP Темп заполнения буфера определяется производной db/dt. Если уровень заполнения достигает Вmax, следующий пришедший сегмент будет
17. NTCP То же, что и на предыдущем рисунке но для протокола NTCP. Здесь протокол, предвидя переполнение
18. NTCP
19. Multipath TCP RFC-6824 TCP Extensions for Multipath Operation with Multiple Addresses
20. Сравнение стандартного TCP и стеков MPTCP-протокола
21. Пример сценария использования MPTCP
22. Формат опций MPTCP
23. Опция MP_CAPABLE A=1 = Необходима контрольная сумма B=0, является флагом расширения с C по H -
24. Опция MP_JOIN (для исходного SYN)
25. Опция Join соединение (MP_JOIN) (для третьего ACK)
26. Пример использования аутентификации в MPTCP
28. Скачать презентацию

Слайд 2

1. Вероятность ошибки доставки (BER) невелика и потеря пакета вероятнее всего

происходит из-за переполнения буфера. Если потеря пакета из-за его искажения существенна, понижение CWND не поможет, и пакеты будут теряться с той же вероятностью (здесь было бы уместно поискать оптимальное значение MTU).
2. Время доставки (RTT) достаточно стабильно и для его оценки можно использовать простые линейные аппроксимации. Здесь подразумевается, что в рамках сессии все пакеты следуют одним и тем же путем и смена порядка прихода пакетов, хотя и допускается, но маловероятна. Разрешающая способность внутренних часов отправителя должна быть достаточно высока, в противном случае возникают серьезные потери из-за таймаутов.
3. Сеть имеет фиксированную полосу пропускания и, во всяком случае, не допускает скачкообразных ее вариаций. В противном случае потребовался бы механизм для прогнозирования полосы пропускания, а действующие алгоритмы задания CWND оказались бы не эффективными
4. Буферы сетевых устройств используют схему первый_вошел-первым_вышел (FIFO). Предполагается, что размер этих буферов соответствует произведению RTT*B (B - полоса пропускания, RTT - сумма времен транспортировки сегмента от отправителя к получателю и времени движения отклика от получателя к отправителю). Если последнее условие нарушено, пропускная способность неизбежно понизится и будет определяться размером буфера, а не полосой пропускания канала

Слайд 3

5. Длительность TCP-сессии больше нескольких RTT, чтобы оправдать используемую протокольную избыточность.

Короткие ТСР-сессии, широко используемые WEB-технологией снижают эффективность обмена. (Именно это обстоятельство вынудило в версиях HTTPv1.1 и выше не разрывать ТСР-соединение после вызова очередной страницы).
6. Чтобы минимизировать влияние избыточности, связанной с заголовком (20 байт IP +20 байт ТСР + МАС-заголовок), используемое поле данных должно иметь большой объем. Для узкополосных каналов, где MTU мало, нарушение данного требования делает канал низкоэффективным. По этой причине выявление допустимого MTU в начале сессии должно приветствоваться.
7. Взаимодействие с другими ТСР-сессиями не должно быть разрушительным, приводящим к резкому снижению эффективности виртуального канала
Данные условия выполняются отнюдь не всегда, и система не рухнет, если эти условия нарушаются часто. Но эффективность работы соединения окажется не оптимальной.

Слайд 4

Трудности в реализации модели протокола ТСР возникли при работе с современными

быстрыми (1-10 Гбит/с) и длинными (RTT>200мсек) каналами. Для пакетов с длиной 1500 байт время формирования окна оптимального размера достигает 83333 RTT (режим предотвращения перегрузки), что при RTT=100мсек составляет 1,5 часа!

Слайд 5

TCP-reno
cwnd(t)=1; ssth(t)=(cwnd(t))/2;
В настоящее время наиболее популярной является модель NewReno, изложенная в

документе RFC-3782 (апрель 2004 года), и использующая алгоритм Fast Retransmit & Fast Recovery. Алгоритм NewReno использует переменную recover (восстановление), исходное значение которой равно исходному порядковому номеру пакета.

Слайд 6

TCP Vegas

Слайд 7

TCP-Tahoe

Слайд 8

Сравнение функций отклика для разных протоколов

Слайд 9

Алгоритм TCP HYBLA
Основной идеей TCP Hybla является достижение для соединений с

большим (напр. спутниковых) тех же скоростей передачи, B(t), что и для проводных TCP-каналов

Слайд 10

Несовершенство версии протокола TCP Newreno для каналов с разными значениями RTT

Слайд 11

CUBIC

Слайд 12

Рост окна в модели CUBIC осуществляется в соответствии с выражением:
W(t) =

C(t-K)3 + Wmax
где C параметр CUBIC, t - время с момента последнего уменьшения ширины окна, а K равно периоду времени, который необходим для увеличения W до Wmax, его значение вычисляется с привлечением выражения:

Слайд 13

Two CUBIC flows with 246ms RTT

Слайд 14

Работа протокола TCP AIMD
Additive-Increase, Multiplicative-Decrease (Область линейного увеличения CWND)
Работа

протокола TCP AIMD в режиме исключения перегрузок можно характеризовать формулой:
BW=
где BW - полоса пропускания;
MSS - максимальный размер сегмента в байтах, используемый сессией.
RTO - таймаут повторной пересылки.
ρ - частота потери пакетов (0.01 означает 1% потерь)
Эта формула является наилучшей аппроксимацией. Некоторое упрощение формулы можно получить, считая RTO=5*RTT.
Более упрощенная формула

Слайд 15

Взаимодействие с чужими потоками
При получении трех дублированных подтверждений (DUPACK) отправитель считает

пакет потерянным и посылает его повторно.
каждое соединение обычно теряет около двух пакетов в каждом эпизоде перегрузки В среднем следует ожидать потерю трех пакетов на одно столкновение.
ECN - Explicit Congestion Notification

Слайд 16

NTCP
Темп заполнения буфера определяется производной db/dt. Если уровень заполнения достигает Вmax,

следующий пришедший сегмент будет потерян. Значение Вmax в общем случае определяется неравенством Вmax > B ×RTT/MSS. Сетевое устройство должно отслеживать уровень заполнения своего буфера. И, если после получения очередного сегмента оказывается, что
(b(t) + db/dt ×RTT + δ) >Вmax,
то всем отправителям-соседям, которые используют данное устройства для передачи данных, должен быть послан отклик с window=0 (сигнал прекращения передачи). δ - конфигурационный параметр.

Слайд 17

NTCP
То же, что и на предыдущем рисунке но для протокола NTCP.

Здесь протокол, предвидя переполнение буфера, реагирует снижением CWND

Слайд 18

NTCP

Слайд 19

Multipath TCP RFC-6824 TCP Extensions for Multipath Operation with Multiple Addresses

Слайд 20

Сравнение стандартного TCP и стеков MPTCP-протокола

Слайд 21

Пример сценария использования MPTCP

Слайд 22

Формат опций MPTCP

Слайд 23

Опция MP_CAPABLE
A=1 = Необходима контрольная сумма
B=0, является флагом расширения
с C по

H - используются для согласования используемого криптоалгоритма.

Слайд 24

Опция MP_JOIN (для исходного SYN)

Слайд 25

Опция Join соединение (MP_JOIN) (для третьего ACK)

Слайд 26