[uanog] Re: [uanog] Re: [uanog] оптимизация TCP/IP

Фактически всё это означает, что [на данном этапе] эта схема неприменима (по масштабированию) на транзитных узлах ввиду своей исключительной завязки на конкретные параметры подключения данного конкретного хоста. Ну или максимум где применима - на шлюзе с ограниченным количеством end-user'ов, для которых нужно держать state machine. И интересно, сколько времени занимает выработка алгоритма оптимизации - в том смысле, что параметры трафика могут меняться существенно быстрее, чем будет происходить анализ для следующей итерации оптимизации. Но для конечного хоста - это да, тема. И тема аккурат для концепции SDN - внешняя система производит весь объем вычислений и анализа транзитного трафика и программирует аппаратуру уже готовым результатом. Мне нравится :-) 2013/7/22 Vladimir Sharun

Там еще один интересный момент был, который здесь опущен: сами специалисты не смогли объяснить, за счет чего и каким образом был получен такой интересный результат.

Далее: на транзитных узлах он подходит, опять таки основной смысл его размещения - маршрутизатор раздачи интернета, т.е. место, где происходит лимит ресурсов (полосы), т.е. этот алгоритм позволяет находить золотую середину между потерей пакетов, скоростью передачи tcp/ip и latency в случае разделяемой среды.

Далее же в каментах было объÑ �снение, почему результат настолько хорош и необъясним: наш мозг не может оперировать таким количеством взаимосвязей, которое анализирует этот алгоритм (200 параметров фигурировало). Т.е. он находит каким-то алгоритмом сношение между десятками параметров, которые идеальным образом обслуживают данный конкртный тип подключения, полосы и всего-всего такого.

Для меня эта статья была в определенном смысле переворотом: это же очень логичное объяснение, почему некоторые идеи нельзя подтвердить иначе, чем только эмпирически: наш моÐ �г невсесилен, а сэмитировать ситуацию с максимальным количеством взаимосвязей практически невозможно. Иначе мы были бы уже завалены продуктами, которые бы нас удовлетворяли на 100% :)

--- Исходное сообщение --- От кого: "Vladimir Litovka" Дата: 22 июля 2013, 15:11:09

"Специалисты из Массачусетского технологического института разработали программу Remy http://web.mit.edu/remy/, которая методом проб и ошибок пыталась улучшить существующие алгоритмы подавления заторов TCP. Результат превзошёл все ожидания. Эффективность алгоритмов RemyCC превзошла и TCP Cubic, и Compound TCP, и остальных «конкурентов» в различных сетевых условиях. " -- http://habrahabr.ru/post/187278/

Отбрасывая некую "желтизну" повествования, есть за этой новостью какой-то смысл? Даже если есть - я сомневаюсь в том, что этот метод может быть каким-либо образом обобщен и, скорее, подходит для оптимизации состояния конкретного TCP/IP стека конкретного конечного узла (компьютера/сервера) и конкретного типа трафика, обрабатываемого этим узлом. И полагаю, что оптимизация на транзитных узлах уже вряд-ли возможна.

В принципе, если код доступен - может кто-нибудь проверить?

-- /doka

-- /doka