|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Lev Walkin 2:5020/400 05 Jun 2003 01:27:50
To : Dmitry Miloserdov
Subject : Re: tcp window
--------------------------------------------------------------------------------
su>
From: Lev Walkin <vlm@netli.com>
Dmitry Miloserdov wrote:
> Hello, Lev!
> You wrote to me on Tue, 3 Jun 2003 21:23:27 +0000 (UTC):
> LW> Hе надо кидаться в частности, плиз. В этом документе - несколько
> LW> устаревшие условия. В других - не очень устаревшие. Метод
> LW> использования "TCP window", рассчитываемого в пакетах, не меняется.
> Устаревшие - действительно не при чем.
> а куча начальных предположений?
> они с таким же успехом могли сказать что-то типа:
> Assume that each TCP segment is 1000 bytes in length.
> эти утверждения никого ни к чему не обязывают.
Когда 1000 - не обязывают. А иной раз говорят: Assume that
each segment is MTU butes in length.
> -----
>
> Лирическое отступление к началу дискуссии (чтобы закрыть кусок темы):
> я утверждал:
> a) что не стоит называть окно в пакетах "tcp window"
Смотря для каких целей!
> б) не стоит для получения "окна в байтах" умножать mtu на что-бы то ни было
> ибо:
> во-первых узнать MTU невозможно.
Хотя почти все TCP реализации ходят на тот уровень, где он есть.
> во-вторых умножать переменные взятые с разных уровней противоречит
> самой идее разделения на уровни.
А передача данных с уровня на уровень случайно идее разделения
на уровни не противоречит? ;)
Шутка.
Hа практике же TCP берет кучу вещей с уровней ниже. Да, противоречит.
Зато a) де-факто и б) так быстрее.
> Про "б)": ты заменил mtu на mss. в такой постановке вопросов нет:
> mss вполне определенная величина и эта величина того же уровня что
> и wnd.
Задам глупый вопрос: откуда берется начальное значение mss?
> Про "а)" сложнее. Под tcp window я понимал все-таки согласованный
> размер т.е. wnd<<wscale. Ты - исключительно внутреннюю для
> отправитля переменную. Что-ж имеешь право, но все-же это
> implementation-depended и даже если получатель не послал
> ни одного ack (кроме syn/ack) он не может быть уверенным
> что отправитель не пошлет ему rcv.wnd целиком.
Верно.
> Да и rfc с cwnd связанные вроде как на стандарт не претендуют,
> судя по апдейтам на bcp пока тоже - т.е. просто анализ существующих
> реализаций.
Приведу единственный пример:
Request for Comments: 2001
Category: Standards Track January 1997
Более того, это как раз то, что спасло интернет от серии коллапсов,
начавшихся в сентябре 1986 года.
> LW> [hp:/u/vlm]>tcpdump -w syns -l -n -vvv 'tcp[tcpflags] & tcp-syn != 0'
> эксперимент интересный но у меня wscale 1 только с хостом
> на котором принудительно net.inet.tcp.recvspace=128k установлен.
Это эксперимент в одной из университетских сеток (несколько сот хостов),
на бэкбоне.
> LW> Hет. Все равно будет стремиться.
> LW> Во-первых, mss изначально будет установлен в MTU непосредственного
> LW> линка. То есть, для ethernet (MTU=1500) в первом же пакете пойдет
> LW> mss=1460:
> ну то что стремится будет не к layer2-mtu а к какому-то абстрактному и
> заранее не предсказумому ты в конце согласился, а более я ничего не
> утверждал
Я бы перефразировал так: если в расшифровке потока видно, что mss ходит
со значением N, то это N можно с большой долей уверенности считать как
наименьший MTU у одного из промежуточных роутеров (PMTU),
примерно так: N = MTU - 40.
В ничтожном проценте случаев можно предполагать, что в середине кто-то
стоит и специально правит mss, но это quite unlikely.
> LW> Во-вторых, во время передачи из-за того, что TCP ставит DF на IP пакет,
> LW> будут происходить ICMP Fragmentation needed and DF set пакеты, а также
> LW> просто дропы (blackhole). По первым TCP стек корректирует свой mss,
> LW> а по вторым - иногда корректирует.
> А вот интересно это поведение (что весь tcp идет с DF) стадартизовано?
> я просто не нашел.
RFC1191, Path MTU Discovery.
Этот документ содержит приложение алгоритма к TCP,
специфицируя MSS option.
=== quote ===
Note: The TCP MSS is defined to be the relevant IP datagram
size minus 40 [9]. The default of 576 octets for the maximum
IP datagram size yields a default of 536 octets for the TCP
MSS.
=== quote ===
--
Lev Walkin
vlm@netli.com
--- ifmail v.2.15dev5
* Origin: Netli, Inc. (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
