Комментарии 58
Прикольно.
Но в реальной жизни проще раскинуть несколько соединений на несколько каналов.
И еще, как оно будет работать, если у разных каналов разный RTT?
Но в реальной жизни проще раскинуть несколько соединений на несколько каналов.
И еще, как оно будет работать, если у разных каналов разный RTT?
Не понял как оно будет работать, если у разных провайдеров разные IP адреса?
UPD:, А, peer тоже должен MPTCP поддерживать.
UPD:, А, peer тоже должен MPTCP поддерживать.
Идея, конечно, прекрасная, но если на одном из маршрутов случился тормоз — тормозит весь коннекшн на всех интерфейсах в ожидании пакета? А если таких коннекшенов сотня? Не очень надежно выглядит, большую инфраструктуру страшно будет строить на таких решениях.
Блин, хабратопик, не содержащий вообще никакой информации :(
Т.е. создается основное TCP соединение, а затем — дополнительные, возможно — с другими адресами. Все они, грубо говоря, разделяют общий буфер.
Есть большие проблемы с преодолением файрволов, которым очень не нравится новая опция TCP. Конечные системы тоже иногда недолюбливают это дело, т.е. у нас проблема с обратной совместимостью.
In brief, here is how MPTCP works. MPTCP is negotiated via new TCP options in SYN packets, and the endpoints exchange connection identifiers; these are used later to add new paths—subflows—to an existing connection. Subflows resemble TCP flows on the wire, but they all share a single send and receive buffer at the endpoints. MPTCP uses per subflow sequence numbers to detect losses and drive retransmissions, and connectionlevel sequence numbers to allow reordering at the receiver. Connection-level acknowledgements are used to implement proper flow control. We discuss the rationale behind these design choices below.
…
To open a new subflow, MPTCP performs a new SYN exchange using the additional addresses or ports it wishes to use.
Т.е. создается основное TCP соединение, а затем — дополнительные, возможно — с другими адресами. Все они, грубо говоря, разделяют общий буфер.
Есть большие проблемы с преодолением файрволов, которым очень не нравится новая опция TCP. Конечные системы тоже иногда недолюбливают это дело, т.е. у нас проблема с обратной совместимостью.
Это-же Ализар.
Я вот не пойму — а в чем прикол этого протокола? ;)
Вот с точки зрения программиста — ничего не меняется, то есть его интерфейс — послали поток байтов — получили поток байтов — и все? А для сервера, который на «доп» соединении — он с какого места в поток байтов вклиниваться будет?
А еще — как виртуальные пути будут другими если ip протокол роутит, не tcp… Только если subflow будут по другому ходить… Не понимаю.
Вот с точки зрения программиста — ничего не меняется, то есть его интерфейс — послали поток байтов — получили поток байтов — и все? А для сервера, который на «доп» соединении — он с какого места в поток байтов вклиниваться будет?
А еще — как виртуальные пути будут другими если ip протокол роутит, не tcp… Только если subflow будут по другому ходить… Не понимаю.
Много TCP потоков — это круто с точки зрения транспорта. Можно по множеству линков размазать один поток данных. С точки зрения клиента это тоже круто, см. одновременную работу вайфая и 3G и сложение скоростей, чего сейчас нет.
На уровень IP это не влияет никак.
На уровень IP это не влияет никак.
Про много круто — я понял.
Я не понял как это технически реализуют, учитывая, что нижележащий протокол TCP — это IP. А в самом tcp даже ip адресов нет.
Вот смотри, есть приложение. заюзало оно mtcp сокет. Захотело пустить два потока разными путями. Ок. Расщепило у себя на tcp уровне эти два потока, и потом на уровень ip пришли два tcp пакета. IP уровень нацепил одинаковые src-dst адреса и отправил одним маршрутом этот праздник к другой точке.
Короче вывод из статьи и комментариев — коммерческий прогон. На досуге почитаю RFC
Я не понял как это технически реализуют, учитывая, что нижележащий протокол TCP — это IP. А в самом tcp даже ip адресов нет.
Вот смотри, есть приложение. заюзало оно mtcp сокет. Захотело пустить два потока разными путями. Ок. Расщепило у себя на tcp уровне эти два потока, и потом на уровень ip пришли два tcp пакета. IP уровень нацепил одинаковые src-dst адреса и отправил одним маршрутом этот праздник к другой точке.
Короче вывод из статьи и комментариев — коммерческий прогон. На досуге почитаю RFC
Понимаете, TCP — это сателлит IP. TCP фактически во всем привязано к IP, вы можете посмотреть все существующие реализации tcp/ip стеков и увидеть модули сопряжения в виде tcp_ip4.c или tcp_ip6.c. Да что говорить, даже контрольные суммы в TCP вычисляются с применением ip заголовков. Поэтому «хак» авторов MPTCP с использованием ip адресов в MP_JOIN и ADD_ADDRESS пакетах вполне рационален. Тем паче, что ASCONF в SCTP работает ну совершенно также, за исключением того факта, что SCTP вообще может иметь собственные чанки для каких-то экзотических сетевых протоколов.
Я понимаю ваше мнение. И согласен с ним. Я просто одного понять не могу. Как существующая L3 инфраструктура поймет, что перед ней mptcp протокол который надо обрабатывать как то по-особому? Надо пойти почитать RFC. :)
L3 инфраструктуре плевать, TCP это, UDP или вообще нечто самописное. Она не смотрит выше IP заголовка.
Но вот и у операторов, и у компаний есть L4-L7 инспектилки (от файрволов и IPS до DPI), те, конечно, могут возненавидеть незнакомый протокол. Но в целом, он очень похож на TCP и многие L4 железки не имеют ничего против него. По словам авторов.
Но вот и у операторов, и у компаний есть L4-L7 инспектилки (от файрволов и IPS до DPI), те, конечно, могут возненавидеть незнакомый протокол. Но в целом, он очень похож на TCP и многие L4 железки не имеют ничего против него. По словам авторов.
Мой первый комментарий в этом треде:«А еще — как виртуальные пути будут другими если ip протокол роутит, не tcp… Только если subflow будут по другому ходить… Не понимаю. „
Я и говорю. Есть один интерфейс на клиенте, открывай потоки, не открывай — все равно пакеты одним маршрутом пойдут, потому что IP. Я это весь топик тут утверждаю. Теперь мое утверждение мне же самому и пришло :)
Я и говорю. Есть один интерфейс на клиенте, открывай потоки, не открывай — все равно пакеты одним маршрутом пойдут, потому что IP. Я это весь топик тут утверждаю. Теперь мое утверждение мне же самому и пришло :)
все равно пакеты одним маршрутом пойдут, потому что IP.
Не совсем.
1) Можно слать и принимать пакеты на разные интерфейсы. Опять же, 3G и Wi-Fi.
2) На самой сети каждый поток данных всегда привязывается к конкретной физической трассе (будь то ECMP или агрегация). Много потоков (разделяются по IP адресам, и да, иногда железо при выборе интерфейса считает хеш на основе в том числе портов отправителя-получателя для увеличения энтропии, так что с «не смотрит выше IP заголовка» я немного наврал, иногда может и посмотреть) = много трасс. Хотя в масштабах оператора это несущественно, там хватает потоков.
3) Все помнят, почему многопоточная закачка на диалапе реально творила чудеса?
1. Так я же пишу — есть один интерфейс. Так уж получается, что у 90% людей (если не у 99%) обычно один интерфейс.
2. Не всегда. Смотреть выше ip заголовка — так протокол то нестандартный.
3. Многопоточная закачка утилизирует всю полосу пропускания, которую не удается утилизировать одним потоком tcp из-за больших задержек на сети.
2. Не всегда. Смотреть выше ip заголовка — так протокол то нестандартный.
3. Многопоточная закачка утилизирует всю полосу пропускания, которую не удается утилизировать одним потоком tcp из-за больших задержек на сети.
Никак. Ей и не надо. Понимает это end hosts. Инфраструктура тупо форвардит как раньше пакеты от src к dst.
см мой ответ тут
Возможно, мне сейчас опять насуют полну попу огурцов, но ведь этот функционал (и не только) уже есть в SCTP, который лучше, легче, быстрее, переносимее, и который вполне себе drop-in replacement для TCP и ряда других протоколов, но которым мало кто пользуется по непонятной причине.
Может быть, кстати, кто-нибудь знает, почему SCTP незаслуженно не используется?
Может быть, кстати, кто-нибудь знает, почему SCTP незаслуженно не используется?
Тоже об этом подумал…
Посмотрите на то, как долго пытаются перейти на IPv6, а ведь это не такой уж сложный и несовместимый протокол.
Проблема заключается в основном в жадности производителей сетевых компонентов.
Можно было бы поддержку IPv6 и SCTP добавить в уже существующие модели роутеров в качестве апдейта. Проблема в том, что уже много денег затрачено в сетевые компоненты, которые все эти протоколы не поддерживают на уровне стандарта. Т.е. всем провайдерам и домашним пользователям нужно обновлять свои коробки.
Были бы апдейты, давно бы уже всё работало, а так за свой счёт никто не хочет менять работающее.
Посмотрите на то, как долго пытаются перейти на IPv6, а ведь это не такой уж сложный и несовместимый протокол.
Проблема заключается в основном в жадности производителей сетевых компонентов.
Можно было бы поддержку IPv6 и SCTP добавить в уже существующие модели роутеров в качестве апдейта. Проблема в том, что уже много денег затрачено в сетевые компоненты, которые все эти протоколы не поддерживают на уровне стандарта. Т.е. всем провайдерам и домашним пользователям нужно обновлять свои коробки.
Были бы апдейты, давно бы уже всё работало, а так за свой счёт никто не хочет менять работающее.
Можно было бы поддержку IPv6 и SCTP добавить в уже существующие модели роутеров в качестве апдейта.
Ну-ну. Учитывая, что примерно все роутеры в интернете хардварные и заточены под конкретную адресацию — ничего сложного апдейтом переделать все чипы-ASICи :)
Хоть сейчас многие начали совать в железки FPGA. Но дорого это.
И даже сейчас, когда всё железо готово к IPv6, остается проблема с софтом. На данный момент IPv4 куда функциональнее, рассматривая завязываемые на него протоколы. Ядро оператора никак не может перейти на v6.
У IPv6 другая проблема. Он вроде как никому не нужен — парадоксально, но факт. Как корпоративный пользователь, я не получу никакой выгоды от внедрения его на своей сети, лишь усложнение существующей архитектуры за счет второго адресного пространства.
С MPTCP и SCTP всё то же самое. TCP работает? Да. Хорошо работает? Да, со всеми костылями. Так смысл шевелиться и что-то менять?
Консерватизм…
> Ну-ну. Учитывая, что примерно все роутеры в интернете хардварные и заточены под конкретную адресацию — ничего сложного апдейтом переделать все чипы
Соглашусь, что это был бы очередной костыль, но на первых порах виртуальную поддержку было бы легче сделать и фиксить в ней баги, чем отлить в чип, а потом выбрасывать баговое железо в помойку.
> У IPv6 другая проблема. Он вроде как никому не нужен — парадоксально, но факт.
С этим не могу согласиться. Один только Global Routing Prefix ведёт к экономии ресурсов в публичном пространстве и больше скорости передачи. Это даже если не говорить, про то, что четвёртые адреса уже на вес золота.
А внутри одной фирмы понятно, что нет огромных преимуществ…
Соглашусь, что это был бы очередной костыль, но на первых порах виртуальную поддержку было бы легче сделать и фиксить в ней баги, чем отлить в чип, а потом выбрасывать баговое железо в помойку.
> У IPv6 другая проблема. Он вроде как никому не нужен — парадоксально, но факт.
С этим не могу согласиться. Один только Global Routing Prefix ведёт к экономии ресурсов в публичном пространстве и больше скорости передачи. Это даже если не говорить, про то, что четвёртые адреса уже на вес золота.
А внутри одной фирмы понятно, что нет огромных преимуществ…
Есть сетевые решения, где виртуальная реализация IP технически невозможна, т.к. софтварной части или вообще нет, или она не занимается непосредственно работой с пакетами. На помойку их никто выкидывать не будет (ибо работает же), а без этого никаких новых протоколов не светит. IPv6 до сих пор остаётся огромной головной болью в этом смысле и источником множества костылей на стороне провайдеров, если бы не фактическое исчерпание адресов IPv4, на такой шаг никогда бы не пошли.
на первых порах виртуальную поддержку
Железо способно молотить IPv4 на line-rate, сотни гигабит или терабиты в секунду.
ЦП тех железок способен передавать пакеты на десятках, край — сотнях мегабит. Это при условии, что архитектура вообще позволяет гонять транзитный трафик через ЦП.
А теперь расскажите поподробнее о том, как вы представляете себе «виртуальную поддержку» :)
Один только Global Routing Prefix ведёт к экономии ресурсов в публичном пространстве и больше скорости передачи.
Ну-ка с этого места поподробнее. С каких пор уменьшение FIB позволит передавать пакеты быстрее, тем более на хардварных платформах, которые априори line-rate?
Экономия ресурсов? Ну ни фига себе экономия, когда первые лет 10 все железки будут держать таблицы минимум удвоенных размеров, половина IPv4, половина IPv6 :)
И красивая агрегация IPv6 — миф, на практике будет та же самая свалка.
И красивая агрегация IPv6 — миф, на практике будет та же самая свалка.
А можно тут подробнее? Например ISP получает префикс IPv6 /32 — его и анонсит. Один префикс, а не стопицот IPv4 как сейчас. Откуда свалка?
НЛО прилетело и опубликовало эту надпись здесь
Ну так анонсируются специфики с разными атрибутами, но в итоге то они все равно агрегируются.
НЛО прилетело и опубликовало эту надпись здесь
ip-transit — проаносировали все специфики свои с разными метриками, например чтобы разнести нагрузку. Та AS, что выступает в роли апстрима агрегирует и уже дальше анонсирует в агрегированном виде. Я пока не могу сообразить, чем это плохо.
Не ip-transit, а простой пиринг — даже если опять анонсируем специфики, а не единый префикс — дальше AS куда анонсируем маршруты не уйдут.
Не ip-transit, а простой пиринг — даже если опять анонсируем специфики, а не единый префикс — дальше AS куда анонсируем маршруты не уйдут.
НЛО прилетело и опубликовало эту надпись здесь
Я все прекрасно понимаю про апстримов — на самом деле предельно ясно, чем черевато анонсирование только части специфик, в случае проблем этого апстрима. И про участие на IX'е, хотя не совсем ясен смысл анонсирования только части специфик участникам. В общем я лишь идеализирую, хотя идеализирую — не совсем верное слово. Я имею ввиду, как кажется правильным поступать, чтобы в итоге не получить подобное тому, что имеем сейчас с ipv4.
FPGA в железках 1000 лет как. И это совсем не дорого. Дорого TCAM и SRAM.
А грустно то, что ни ipv6, ни sctp, ни этот mptcp так и не решают проблему IP/Loc separation.
А грустно то, что ни ipv6, ни sctp, ни этот mptcp так и не решают проблему IP/Loc separation.
FPGA в железках 1000 лет как.
Да неужели? :)
Можно примеры операторского железа от C/J 10-летней давности с FPGA?
Ну положим LISP — это с какой-то точки зрения красиво, но у меня есть серьезные сомнения, что оно будет на практике внедряться в глобальном масштабе. Слишком много идет споров буквально по каждой мелочи. Слишком непонятно, как оно должно в итоге выглядеть.
Ну и каким образом L4 протокол должен решить проблему IP/Loc separation? Я себе это плохо представляю…
FPGA — это просто матрица, в которую можно залить некий «алгоритм». В той же 7600 их полно.
Не лиспом единым. Он наиболее раскручен, есть и другие варианты. Правда существуют они не более чем в письмах в соответствующие рассылки ietf.
Не лиспом единым. Он наиболее раскручен, есть и другие варианты. Правда существуют они не более чем в письмах в соответствующие рассылки ietf.
Так на каких линейных картах 10-летней давности стоят FPGA?
На самом деле решений по IP/Loc separation до черта и больше, вплоть до MPLS VPN. Только вот с глобальными масштабами обычно проблема…
На самом деле решений по IP/Loc separation до черта и больше, вплоть до MPLS VPN. Только вот с глобальными масштабами обычно проблема…
OSM/SIP/SPA.
В глобальном масштабе да, малой кровью не получается. Видимо надо ждать когда всем существующее положение вещей надоест настолько, что сломать будет проще, чем прикручивать очередной костыль.
В глобальном масштабе да, малой кровью не получается. Видимо надо ждать когда всем существующее положение вещей надоест настолько, что сломать будет проще, чем прикручивать очередной костыль.
OSM/SIP/SPA — это не линейные карты ;) Вы же не будете ставить 7600 только с SIPами, это было бы странно.
Что до «надоест»… Мощь железа растет быстрее, чем количество префиксов/маршрутов. Если, конечно, не увлекаться запихиванием full view в VRFы. Возможно, существующее положение вещей никогда никому не надоест.
Что до «надоест»… Мощь железа растет быстрее, чем количество префиксов/маршрутов. Если, конечно, не увлекаться запихиванием full view в VRFы. Возможно, существующее положение вещей никогда никому не надоест.
А что же это такое, если не линейные карты?
SIP для 7600 плавно эволюционировал до ES20. Сейчас уже их никто ставить не будет, но вот 10 лет назад приходилось. Именно FPGA там и занимались тем, что реализовывали «сервис», которого нет на LAN картах типа 6704.
SIP для 7600 плавно эволюционировал до ES20. Сейчас уже их никто ставить не будет, но вот 10 лет назад приходилось. Именно FPGA там и занимались тем, что реализовывали «сервис», которого нет на LAN картах типа 6704.
SIP (и ES) — это фактически отдельный роутер, устанавливаемый в шасси. И у него очень дорогие порты. Что-то я не слышал о практическом использовании 7600, не утыканных 61XX, 65XX или 67XX платами…
С чего бы это вдруг?
ES — обычная линейная карта, которая за счет FPGA умеет всякие фичи. Тот же VPLS вспомнить, перезапись тегов, QoS. Естественно это все дороже, чем тупые LAN карты. Но денег много не бывает, поэтому их особо никто и не покупал. Или брали для пары роутеров и делали «сервис» на нем.
Но это никак не отменяет тот факт, что FPGA там были.
ES — обычная линейная карта, которая за счет FPGA умеет всякие фичи. Тот же VPLS вспомнить, перезапись тегов, QoS. Естественно это все дороже, чем тупые LAN карты. Но денег много не бывает, поэтому их особо никто и не покупал. Или брали для пары роутеров и делали «сервис» на нем.
Но это никак не отменяет тот факт, что FPGA там были.
LISP сможет глобально захватить чтото если EID начнут продавать как домены. Обсуждалось недавно в WG LISP. Иначе так и останеться эксперементальным ну или будет свою иметь лишь нишу.
Одно лишь только слово: инфраструктура.
Любое изменение в L3/L4 чревато изменениями во всём сетевом оборудовании по всему миру. Это трудно, а иногда и невозможно.
Для различных внутренних сетей, где вся инфраструктура под контролём, альтернативы очень даже применяются, если это целесообразно.
Любое изменение в L3/L4 чревато изменениями во всём сетевом оборудовании по всему миру. Это трудно, а иногда и невозможно.
Для различных внутренних сетей, где вся инфраструктура под контролём, альтернативы очень даже применяются, если это целесообразно.
Ну для начала следует сказать что в Windows нету поддержки SCTP, только через сторонних производителей. В мак ос тоже кстати нету, хотя казалось бы особенно для IOS логично было бы там использовать sctp, ибо всегда есть 2 разных сетевых интерфейса да и ОС и сервера контролирует одна компания.
Принципиальные проблемы SCTP — поддержка offload со стороны железа, причем, как сегментации, так и контрольных сумм, и проблема middlebox'ов. Хотя чексуммы некоторые top level сетевые карты уже умеют делать, то с сегментацией пока что еще все плохо. С другой стороны, у MPTCP самого полно проблем, в частности съедание остатков options space в пакете, невозможность использовать ECN для общего congestion control, наивный подход к добавлению адресов (который, к тому же имеет ряд проблем с безопасностью), отсутствие поддержки FAST OPEN (которая у SCTP из коробки), невозможность правильного управления SACK (хотя у SCTP только сегодня вышел драфт по решению этой проблемы). Ну а вообще, ребята из MPTCP команды сделали много очень правильных улучшений в плане производительности, но в общем случае они неприменимы: отключена поддержка coupled checksums, для отправки данных в сеть используется sendfile ring buffer, который, в общем случае ведет к неконтролируемым расходам памяти, для приема используется NetDMA (который опять же предполагает offloading для контрольных сумм). Но самый большой плюс MPTCP в том, что если middlebox'ы режут нам все опции, режут SCTP, то TCP все равно работает.
НЛО прилетело и опубликовало эту надпись здесь
Тоже сразу об этом подумал. Подозреваю, что с точки зрения теории информационной безопасности, этот протокол — как на небосклоне новое созвездие «Большой писец».
На самом деле, сложность абсолютно одинакова, для аутентификации потоков используется общий ключ, генерируемый на базе HMAC хеш-функции. Так что, разумеется, это не устраняет опасность данной атаки, но и не упрощает ее. А вот то, что хост светит всеми ip сразу, а также, что есть возможность DoS атаки на out-of-order queue, — это реальность.
А SCTP теперь на помойку?
Ну вы что, городить велосипеды же так интересно. А SCTP и правда жаль, ведь он именно для этих целей и создавался. А если еще вспомнить преимущества при работе в потоке и отсутствии TCP-шных проблем с размером окна, то становится совсем грустно.
А еще SCTP кристально прозрачен и понятен по сравнению с TCP — те, кто писал свою реализацию TCP, меня поймут.
И он может в юзерспейсе работать поверх UDP с совсем незначительными изменениями.
И он может в юзерспейсе работать поверх UDP с совсем незначительными изменениями.
Он-то понятен, но с точки зрения роутера или firewall'а обрабатывать единый стандарт пакетов намного проще, чем все варианты чанков SCTP.
Роутеру или файрволу вообще плевать, по большей части, что он обрабатывает.
Под флаги у TCP отведено 9 бит, у SCTP под тип чанка — 8 бит, итого TCP потенциально в два раза труднее для обработки. К сожалению, я не скажу сходу, сколько у TCP допустимых комбинаций флагов, т.к. в его спецификации черт ногу сломит. В SCTP на данный момент 15 типов (2 из них зарезервированы), и это совсем, совсем немного.
Под флаги у TCP отведено 9 бит, у SCTP под тип чанка — 8 бит, итого TCP потенциально в два раза труднее для обработки. К сожалению, я не скажу сходу, сколько у TCP допустимых комбинаций флагов, т.к. в его спецификации черт ногу сломит. В SCTP на данный момент 15 типов (2 из них зарезервированы), и это совсем, совсем немного.
Плюс в мире не существует ни одной безглючной реализации фаервола, который бы без проблем для хостов мог вмешиваться в tcp диалоги. Что pix, что asa несут в себе массу скрытой попоболи при включении данного функционала.
До тех пор, пока он не делает трансляцию адресов, ресегментацию и не помогает транспортному congestion control, да, наплевать. И все это требует пересчета чексуммы пакета. А последние две функции вообще требуют полного понимания работы транспортного протокола. И в случае TCP мы имеем *фиксированный* формат пакета, расширяемый только опциями до 40 байт (причем тут вы упомянули флаги, я вообще не понимаю), то в случае SCTP мы должны лезть внутрь чанков, которые имеют свои описания.
кто может повторить и выложить pcap запись эксперимента?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Многопутевая (multipath) модификация для протокола TCP: первый эксперимент