|
ru.cisco
- RU.CISCO ---------------------------------------------------------------------
From : Alex Semenyaka 2:461/640.640 22 Feb 2008 11:58:16
To : Eugene Grosbein
Subject : Посоветyйте пpавильное напpавление
--------------------------------------------------------------------------------
21 Feb 08 16:47, you wrote to me:
AS>>>> Ага, и из-за переупорядочивания начнутся перепосылки TCP. Очень
AS>>>> удобно.
EG>>> Почему перепосылки, буфера кончатся? Такие маленькие?
AS>> Потому что три пакета (второй, третий и четвёртый) пойдут по одному
AS>> каналу, а
AS>> один (первый) по другому. По получению трёх одинаковых ACK от этих
AS>> вот трёх отправитель начнёт процедуру быстрого восстановления, то
AS>> есть сбросит скорость до 1 пакета на RTT и пошлёт заново якобы
AS>> потерянный первый пакет. Hу и границу перехода к режиму
AS>> предотвращения перегрузки опустит. Я ж говорю - очень удобно, да.
EG> SACK не спасёт?
Чем? Тем, что размер "дырки" точно опишет? :)
Ты, кажется, слабо понимаешь. SACK и иже с ними решают проблему, когда потеря
на самом деле _есть_.
А в твоём случае только кажется, что она есть, а на самом деле её _нет_, а есть
её видимость из-за кривизны сетевого дизайна. И эту ситуацию ты никак
средствами протокола не победишь.
Я молчу уж про то, что в Самой Популярной Ос (tm) SACK надо явным образом
включать (что эквивалентно его отсутствию).
SN>>>>>> А если вспомнить про IP-телефонию...
EG>>>>> В этом случае eigrp + per-flow :-)
AS>>>> Да и вообще eigrp в попу.
EG>>> Если на L3, то должен же кто-то маршруты переписывать.
AS>> "Кто-то" != EIGRP
EG> А хто?
OSPF?
Alex
--- IMHO в последней инстанции
* Origin: ...можжевеловых... (2:461/640.640)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
