|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Lev Walkin 2:5020/400 04 Jun 2003 01:23:27
To : Dmitry Miloserdov
Subject : Re: tcp window
--------------------------------------------------------------------------------
Dmitry Miloserdov wrote:
> Hello, Lev!
> You wrote to me on Mon, 2 Jun 2003 18:41:49 +0000 (UTC):
> LW> Разрешите возразить ссылкой:
> LW> http://www.psc.edu/networking/papers/tcp_friendly.html
> LW> === cut ===
> LW> Assume that the TCP connection has MTU bytes/packet, and a roundtrip
> LW> time of RTT seconds. Assume that, when a packet is dropped, the TCP
> LW> connection had a window of W packets, and was sending at an average
> LW> rate (over that roundtrip time) of
> LW> S = W * MTU / RTT
> LW> === cut ===
> Возможно я просто не совсем понял что понималось под исследованиями.
> Столь формальные я конечно не мог иметь ввиду.
> Все эти предположения скорее говорят о том что их MTU к реальному
> mtu отношения не имеют, тоже самое и про window. Да и от tcp там
> осталось только сама идея "congestion window" да и то с несколько
> устаревшими
> начальными условиями.
Hе надо кидаться в частности, плиз. В этом документе - несколько
устаревшие условия. В других - не очень устаревшие. Метод
использования "TCP window", рассчитываемого в пакетах, не меняется.
> LW> В исследованиях, подобных вышеуказанному, могут приниматься
> LW> следующие условности:
> LW> 1. TCP Window является производной от RCV.WND и SND.CWND.
> LW> 2. CWND стандартизован в байтах (RFC2001), но некоторые
> LW> операционки (Linux) хранят SND.CWND сегментах (соответственно,
> LW> умножаемые на mss для получения размера в байтах). BSD
> LW> хранит SND.CWND в байтах. Соответственно, величину TCP Window
> LW> для формул можно и нужно брать в любых единицах, важно только
> LW> указать, в каких.
> Hе суть.
> принципиальная разница только между пакетами и байтами
> а в каком виде хранить в системе дело разработчиков.
Верно, но не тогда, когда на практике:
а) хранят и в байтах, и в пакетах одновременно, даже в пределах одной ОС;
б) в пакете уже давно обращать внимание на поле в байтах не имеет
смысла. даже если wscale не используется почти. от обязанности его
смотреть никто не освобождает. (утрирую немного, но все-таки).
поэтому, и там и там - составные попугаи.
> ex: "Q: сколько тут до пункта X? A: 6 перекрестков. Q: а сколько это в
> километрах?"
> если ответ будет "A: 1300 метров" то вопросов не возникнет.
> а если скажут "A: 5минут"?
О единицах нужно договариваться в самом начале. А не спорить о том,
в чем это измеряется постфактум. Как раз мое оригинальное письмо - об
этом.
> LW> 3. В пакете окно передается как комбинация поля window (16 бит)
> LW> плюс (после 1323 (1072)) window scale option, так что говорить
> LW> об окне в байтах _в пакете_ уже давно смысла нет.
> Дэ юро - да. Дэ факто - tcp-options ходят но обычно scale=0.
> практически никто же не меняет размер буфера.
Вот это - верно.
[hp:/u/vlm]>tcpdump -w syns -l -n -vvv 'tcp[tcpflags] & tcp-syn != 0'
...
[hp:/u/vlm]>tcpdump -n -r syns | grep "wscale [1-9]" | wc
2536 38719 406930
[hp:/u/vlm]>tcpdump -n -r syns | wc
306112 4120263 41760540
> LW> 4. При необходимости получить итоговую величину в байтах сегменты
> LW> (пакеты) нужно умножать на средний размер пакета. При исследованиях
> LW> установившегося потока, то есть, при исследованиях максимальной
> LW> пропускной способности виртуального соединения TCP, средний
> LW> размер пакета будет стремиться к mss, а mss будет стремиться
> LW> к MTU.
> Если под mtu ты понимаешь тот mtu который с link layer'а
> то не согласен. mtu у отправителя может быть гораздо больше
> и на уровне ip фрагментироваться/собираться. ну или наоборот
> меньше.
Hет. Все равно будет стремиться.
Во-первых, mss изначально будет установлен в MTU непосредственного
линка. То есть, для ethernet (MTU=1500) в первом же пакете пойдет
mss=1460:
[vlm@spelio:/home/vlm]>tcpdump -n -vvv port 80
tcpdump: listening on fxp0
14:18:15.996355 172.17.1.103.4328 > 62.118.252.77.80: S [tcp sum ok]
1862106489:1862106489(0) win 65535 <mss 1460,nop,wscale
1,nop,nop,timestamp 68200635 0> (DF) [tos 0x10] (ttl 64, id 65306, len 60)
(кстате, заметь wscale в этом примере - результат простого
telnet'а в соседнем окне).
Во-вторых, во время передачи из-за того, что TCP ставит DF на IP пакет,
будут происходить ICMP Fragmentation needed and DF set пакеты, а также
просто дропы (blackhole). По первым TCP стек корректирует свой mss,
а по вторым - иногда корректирует.
Поэтому, mss все-таки будет стремиться к MTU. Какого линка, и линка
ли - это уже другой вопрос. Может на intermediate гейте размер MTU
маленький для пакета, либо там стоит mss-ковырялка, которая меняет
mss в проходящих пакетах.
Впрочем, я согласен, что MTU тут более абстрактный, чем просто
MTU линка: слишком много факторов в реале. Hо то, что это значение
модулируется именно MTU линка (минимального на пути пакета),
это факт.
--
Lev Walkin
vlm@netli.com
--- ifmail v.2.15dev5
* Origin: Netli, Inc. (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
