Там еще один интересный момент был, который здесь опущен: сами специалисты не смогли объяснить, за счет чего и каким образом был получен такой интересный результат.
Далее: на транзитных узлах он подходит, опять таки основной смысл его размещения - маршрутизатор раздачи интернета, т.е. место, где происходит лимит ресурсов (полосы), т.е. этот алгоритм позволяет находить золотую середину между потерей пакетов, скоростью передачи tcp/ip и latency в случае разделяемой среды.
Далее же в каментах было объ�
�снение, почему результат настолько хорош и необъясним: наш мозг не может оперировать таким количеством взаимосвязей, которое анализирует этот алгоритм (200 параметров фигурировало). Т.е. он находит каким-то алгоритмом сношение между десятками параметров, которые идеальным образом обслуживают данный конкртный тип подключения, полосы и всего-всего такого.
Для меня эта статья была в определенном смысле переворотом: это же очень логичное объяснение, почему некоторые идеи нельзя подтвердить иначе, чем только эмпирически: наш мо�
�г невсесилен, а сэмитировать ситуацию с максимальным количеством взаимосвязей практически невозможно. Иначе мы были бы уже завалены продуктами, которые бы нас удовлетворяли на 100% :)
--- Исходное сообщение ---
От кого: "Vladimir Litovka" <
doka.ua@gmail.com>
Дата: 22 июля 2013, 15:11:09
"Специалисты из Массачусетского технологического института разработали программу
Remy,
которая методом проб и ошибок пыталась улучшить существующие алгоритмы
подавления заторов TCP. Результат превзошёл все ожидания. Эффективность
алгоритмов RemyCC превзошла и TCP Cubic, и Compound TCP, и остальных
«конкурентов» в различных сетевых условиях. " --
http://habrahabr.ru/post/187278/Отбрасывая некую "желтизну" повествования, есть за этой новостью какой-то смысл? Даже если есть - я сомневаюсь в том, что этот метод может быть каким-либо образом обобщен и, скорее, подходит для оптимизации состояния конкретного TCP/IP стека конкретного конечного узла (компьютера/сервера) и конкретного типа трафика, обрабатываемого этим узлом. И полагаю, что оптимизация на транзитных узлах уже вряд-ли возможна.
В принципе, если код доступен - может кто-нибудь проверить?
--
/doka