Здравствуйте, netch80, Вы писали:

N>Принципы формирования локальной части IPv6 адреса, не пересекающейся с EUI-64, отданы на откуп локальным правилам. Тем более то, что ты описал, это на 200% внутренняя кухня и не имеет отношения к обсуждаемым вопросам.

SRv6 (Segment routing на IPv6) как пример не-внутренней кухни

Здравствуйте, Shmj, Вы писали:

S>Вот, что имеем

Здравствуйте, Vetal_ca, Вы писали:

N>>Принципы формирования локальной части IPv6 адреса, не пересекающейся с EUI-64, отданы на откуп локальным правилам. Тем более то, что ты описал, это на 200% внутренняя кухня и не имеет отношения к обсуждаемым вопросам.

V_>SRv6 (Segment routing на IPv6) как пример не-внутренней кухни

Нет, это такая же внутренняя — для транспортного провайдера. Ещё один способ нарисовать внешнюю сторону туннеля.

Здравствуйте, netch80, Вы писали:

N>Нет, это такая же внутренняя — для транспортного провайдера. Ещё один способ нарисовать внешнюю сторону туннеля.

Ну не приватный же хакинг конкретной конторы по IPv6, вполне публичная технология.

Здравствуйте, netch80, Вы писали:

SK>>В раутере этим аппаратно занимается ASIC (ПЛМ), таки специализированный "128 битный процессор".

N>Во-первых, пусть ASIC — и в нём всё равно младшую часть адреса не проверяют, пока не приходит время разбираться, куда же раутить именно на непосредственно подключенный интерфейс (а не на уже известный шлюз следующего хопа).

И это логично. зачем делать полную проверку адреса на каждом транзитном раутере?

N>Во-вторых, далеко не всё может пройти этим путём. Разработчики раутеров, конечно, пытаются вынести по максимуму на уровень FPGA/ASIC/etc., но чуть шаг в сторону от привычного пути — привет, центральный процессор и просадка по CPS в 3-4 раза (даже если тому процессору работа вылизана до предела).

Это происходит в случаях плохого дизайна сети, когда архитектор заставляет раутер выполнять противоестественные функции другого устройства.

SK>>Тут у нас очевидная проблема, что Shmj думает что в раутеры ставят х86_64 пентиумы процессоры общего назначения под управлением линукса операционной системы общего назначения.



SK>>>>Эмоции убери в сторону. Избыточность ещё не доказана.

N>>>Доказана тем, что никто не смог выдвинуть достойных аргументов в её пользу. Лучшее, что есть, это "уже сделали, менять поздно".

SK>>Сделали с учетом недостатков IPv4 с большим запасом. что б не возвращаться к этому вопросу ближайшие 50 лет.

N>Да тут не 50, тут на 100 размахнулись. И вот это плохо — потому что за это время точно что-то должно было измениться в подходе.

Если и изменится подход, то будет запас времени тщательно продумать, а не аврально подставлять костыли.

SK>>Единственный реальный недостаток — недружелюбный к человеку формат адреса (трудно читаемый, трудно произносимый, не запоминаемый).

N>Не единственный, если на то пошло.
N>Надо было как минимум ещё порты расширить до 32 бит.
N>Но они почему-то не решились менять и заголовки транспортных уровней.

Потому что портов хватает? Сколько их сейчас занято? 6-7 тысяч? еще 50к остаются свободными. на практике я не припоминаю хостов, которые использовали б больше 700, а обычно меньше 100.

Все проблемы от жадности и глупости

Здравствуйте, B0FEE664, Вы писали:

BFE>От себя добавлю, что если для поиска использовать B-Tree с ключом в байт, то разница между 8-байтовым адресом и 16 байтовым адресом будет всего 8 операций сложения и 8 операций сравнения, что не выглядит чем-то из-за чего стоит переживать.

Вы понимаете что такое нейтивный тип для процессора? На всех уровнях вычисления с не нейтивыным типом будут на порядок больше ресурсов занимать. Те же 16 операций — это и будет на порядок+. Т.е. получаем замедление в 10 раз на каждом этапе.

Или же удорожение процессоров — добавление 128 битных типов ради ничего.

Здравствуйте, Stanislaw K, Вы писали:

S>>Обясни как на сравнение 16 байтных значений тратиться 1 такт, если нет такого нейтивного типа в архитектуре процессора.

SK>0) сравниваются биты.

Когда работаешь с типами, для которых нет нейтивного представления — вычисления занимают намного больше ресурсов. Намного. Не в два раза а на порядок.

SK>1) такой тип в архитектуре процессора есть.

Добавление 128-битной архитектуры — это только спец. процессоры и стоят они очень дорого. При этом шина все-равно 64 бита, т.к. ОЗУ и все прочее — делается под 64 бита.

Здравствуйте, Serginio1, Вы писали:

S> Это сложно? Или ты хочешь искать проходя по всем адресам?
S>Зачем хэш таблицу то придумали?

Это отнимает на порядок больше ресурсов.

Здравствуйте, Pavlo Smaktunovskiy, Вы писали:

PS>Image: Technology-Quiz-8-320.jpg

Это не значит теперь, что всегда будет мало. Разумность должна быть. Исходи из количества людей, которые потенциально способны жить на Земле а так же количестве девайсов для каджого.

Я беру — 1 триллион людей и 16 млн. девайсов у каждого — потолок.

Чтобы тебе было понятно. Изначально сделали половой член в 4 дюйма, что явно мало. Я предлагаю сделать 8 дюймов и утверждаю что больше не нужно. А по стандарту же сделали 16 дюймов, т.к. боялись что не хватит. Ты хочешь 16 дюймов?

Здравствуйте, Shmj, Вы писали:


SK>>1) такой тип в архитектуре процессора есть.

S>Добавление 128-битной архитектуры — это только спец. процессоры и стоят они очень дорого. При этом шина все-равно 64 бита, т.к. ОЗУ и все прочее — делается под 64 бита.

Ты отрицаешь существование самолетов на том основании что в своей жизни не видел ничего кроме велосипедов.

Рынок сетевых устройств огромен, "спец. процессоры" заточенные на аппаратное выполнение одной задачи при тиражах в десятки миллионов штук стоят десятки центов. Не в каждой, но во многих сетевых картах внутри есть подобный процессор (меньшей производительности чем в маршрутизаторах, но тем неменее) на который драйвером выносится часть работы с сетью для разгрузки CPU.

Объем ОЗУ требующегося там — десятки килобайт, выносить его в отдельные чипы вообще нет смысла.
При современных скоростях в десятки и сотни гигабит это просто привело бы к фатальному снижению производительности.

Как и любая попытка произвести какие-либо "вычисления" над ip адресом любого формата.

Все проблемы от жадности и глупости

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, vsb, Вы писали:

S>И никаких оправданий этому быть не может — просто лишняя трата ресурсов на каждом девайсе. Начиная с удорожения самих девайсов, которые должны поддерживать 128-битные операции.

сейчас каждый девайс должен уметь в жсон, т.к. на нем 90% интернета работает.

Здравствуйте, Stanislaw K, Вы писали:

SK>>>В раутере этим аппаратно занимается ASIC (ПЛМ), таки специализированный "128 битный процессор".
N>>Во-первых, пусть ASIC — и в нём всё равно младшую часть адреса не проверяют, пока не приходит время разбираться, куда же раутить именно на непосредственно подключенный интерфейс (а не на уже известный шлюз следующего хопа).
SK>И это логично. зачем делать полную проверку адреса на каждом транзитном раутере?

Не логично то, что это приведёт к тому, что все попытки использовать меньшую ширину блока на локалку будут разбиваться уже о сопротивление производителей железа.

N>>Во-вторых, далеко не всё может пройти этим путём. Разработчики раутеров, конечно, пытаются вынести по максимуму на уровень FPGA/ASIC/etc., но чуть шаг в сторону от привычного пути — привет, центральный процессор и просадка по CPS в 3-4 раза (даже если тому процессору работа вылизана до предела).
SK>Это происходит в случаях плохого дизайна сети, когда архитектор заставляет раутер выполнять противоестественные функции другого устройства.

Только что-то этот "плохой дизайн" происходит в подавляющем большинстве сетей, когда они не укладываются в гениальные задумки мудрецов из башен из слоновой кости.

N>>Да тут не 50, тут на 100 размахнулись. И вот это плохо — потому что за это время точно что-то должно было измениться в подходе.
SK>Если и изменится подход, то будет запас времени тщательно продумать, а не аврально подставлять костыли.

Нет, практика показывает, что продумывать никто не будет. Просто к одним костылям добавятся другие.

N>>Не единственный, если на то пошло.
N>>Надо было как минимум ещё порты расширить до 32 бит.
N>>Но они почему-то не решились менять и заголовки транспортных уровней.
SK>Потому что портов хватает? Сколько их сейчас занято? 6-7 тысяч?

Ты считай не по формально распределённым под конкретные цели, а в целом и по динамическим назначениям. Во внутренних сетях в это постоянно упираются, когда их не хватает на исходящие соединения. Приходится костылить через много хостовых адресов.

SK> еще 50к остаются свободными. на практике я не припоминаю хостов, которые использовали б больше 700, а обычно меньше 100.

Я видел, как просто не было из чего создать новое соединение.

Здравствуйте, Shmj, Вы писали:

S>Добавление 128-битной архитектуры — это только спец. процессоры и стоят они очень дорого.

Вот тут ты загнался.

Сколько стоит процессор типа, например, AArch64 с обязательной поддержкой SIMD на 128 бит? Неплохие версии такого уровня младших малинок можно купить оптом за 5$ штука. С продвинутым контроллером памяти и прочими вкусными плюшками будет ну 20$. Понятно, топовые будут и 1000$, но это условный аналог Xeon.

Сколько стоит минимальный процессор типа x86 Atom современного поколения? Специально смотрю самый дешёвый... D2550 это 47$. x7203C это 39$. Не знаю, за что сколько, но на "очень дорого" не тянет. И они все умеют SSE вплоть до 4.2.

Можно ещё RISC-V посмотреть, с векторными командами на 128 бит. Вот например целые одноплатники от 17$. Процессор так вообще там наверняка меньше 5$.

Где тут, повторюсь, "очень дорого"??? Это совершенно базовый уровень...

При этом просто сравнение на вхождение в сеть на полную ширину делается парой векторных команд. Единственная не-векторная операция это преобразование длины префикса в маску или наоборот. Ну для таких задач на неё можно и отдельную команду сделать (которая заглянет в небольшое внутреннее ПЗУ или упрощённый вариант бочки сдвига).

Ты застрял мышлением где-то в 2000 году.

S> При этом шина все-равно 64 бита, т.к. ОЗУ и все прочее — делается под 64 бита.

Два такта вместо одного. Невелика потеря. Главное, что она тут линейная. (На самом деле в самом важном случае — магистральный раутер — работа идёт только со старшими 64 битами. Тоже упоминал несколько раз.)

Здравствуйте, netch80, Вы писали:

S>> Ты серьезно? Там поиск по хэштаблице.

N>Прекратите курить эти опилки, плохой дым получается. Никакие хэш-таблицы непригодны в принципе, потому, что поиск должен срабатывать по _неточному_ совпадению (базовый адрес плюс длина сети покрывает этот адрес) с наиболее длинным префиксом. Хэш-таблицы срабатывают только при полном совпадении.
N>Всякие AVL/RB/B-tree тоже не годятся, потому что может быть, что совпадает не тот, у кого ближайший базовый адрес, а тот, у кого сеть накрывает этот адрес.

N>Там Radix tree в бинарном варианте. При совпадении пары baseaddr+prefixlen у двух записей срабатывает метрика (меньше — важнее).
N>Бывает ещё больше параметров.

N>Поясняю на примере: пусть есть записи:

N>10.1.2.0/23 (то есть 10.1.2.0...10.1.3.255)
N>10.1.0.0/16 (то есть 10.1.0.0...10.1.255.255) с метрикой 10.
N>10.1.0.0/16 опять же, с метрикой 20.
N>10.0.0.0/8 (то есть 10.0.0.0...10.255.255.255)
N>10.1.3.0/27 (то есть 10.1.3.0...10.1.3.31)

N>Для 10.1.3.4 сработать должен 10.1.3.0/27, потому что у него самый длинный префикс.

N>Для 10.1.244.1 сработает 10.1.0.0/16 с метрикой 10, базовые адреса и длины префикса одинаковые, включается метрика.

N>(Метрика задаётся источником. Например 0 — directly connected, 1 — static, дальше идут в определённом порядке внутренние динамические протоколы, потом внешние.)

Спасибо буду знать. Я про то, что никто не будет просто чесать по всем адресам, будет алгоритм для как минимум бинарного поиска.
В твоем примере это деревья.
Shmj то пишет, что проблемы в процессоре. При бинарном поиске все эти затраты нивелируются

Здравствуйте, netch80, Вы писали:

SK>>И это логично. зачем делать полную проверку адреса на каждом транзитном раутере?

N>Не логично то, что это приведёт к тому, что все попытки использовать меньшую ширину блока на локалку будут разбиваться уже о сопротивление производителей железа.

У нас, на планете Земля, как-то не принято пока ещё строить полносвязные сети "каждый с каждым". 1-2 редко 3-4 WAN аплинка на раутер, 1-2 редко 3-4 LAN. Таким образом таблица маршрутизации и ширина блока имеют разумную величину, не смотря на то что даже средний SOHO раутер может больше.


SK>>Это происходит в случаях плохого дизайна сети, когда архитектор заставляет раутер выполнять противоестественные функции другого устройства.

N>Только что-то этот "плохой дизайн" происходит в подавляющем большинстве сетей, когда они не укладываются в гениальные задумки мудрецов из башен из слоновой кости.

утренний стаканчик смузи не заменяет образования и опыта.

SK>>Потому что портов хватает? Сколько их сейчас занято? 6-7 тысяч?

N>Ты считай не по формально распределённым под конкретные цели, а в целом и по динамическим назначениям. Во внутренних сетях в это постоянно упираются, когда их не хватает на исходящие соединения. Приходится костылить через много хостовых адресов.

SK>> еще 50к остаются свободными. на практике я не припоминаю хостов, которые использовали б больше 700, а обычно меньше 100.

N>Я видел, как просто не было из чего создать новое соединение.

Такое я тоже встречал, очень давно. Причина та-же: плохой дизайн/непродуманная архитектура.

"Делаю гов## плохо, потому что могу!"

При таком подходе к проектированию и IPv6 и FFFF портов вместе взятые быстро исчерпаются.

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

SK>Рынок сетевых устройств огромен, "спец. процессоры" заточенные на аппаратное выполнение одной задачи при тиражах в десятки миллионов штук стоят десятки центов. Не в каждой, но во многих сетевых картах внутри есть подобный процессор (меньшей производительности чем в маршрутизаторах, но тем неменее) на который драйвером выносится часть работы с сетью для разгрузки CPU.

SK>Объем ОЗУ требующегося там — десятки килобайт, выносить его в отдельные чипы вообще нет смысла.

ОЗУ для домашнего раутера мы не смотрим, а вот если нужно вгрузить в такой процессор BGP fullview, то это сейчас ~3MB только на IPv6 на адреса с масками, а если получатели и атрибуты то ещё раза в 3-4 больше, а если IPv4 то ещё удвоить.
Но сейчас и 32MB SRAM тривиально делается в одной микрухе, так что тут проблем таки нет. Моё замечание относится к порядку цифр, но не принципу.

SK>При современных скоростях в десятки и сотни гигабит это просто привело бы к фатальному снижению производительности.

SK>Как и любая попытка произвести какие-либо "вычисления" над ip адресом любого формата.

Поиск по radix tree по базе и маске это вполне вычисления.

Здравствуйте, Stanislaw K, Вы писали:

SK>>>И это логично. зачем делать полную проверку адреса на каждом транзитном раутере?

N>>Не логично то, что это приведёт к тому, что все попытки использовать меньшую ширину блока на локалку будут разбиваться уже о сопротивление производителей железа.

SK>У нас, на планете Земля, как-то не принято пока ещё строить полносвязные сети "каждый с каждым". 1-2 редко 3-4 WAN аплинка на раутер, 1-2 редко 3-4 LAN. Таким образом таблица маршрутизации и ширина блока имеют разумную величину, не смотря на то что даже средний SOHO раутер может больше.

А они неинтересны в плане текущей дискуссии. Интересны те, которые работают под максимальной нагрузкой. А это те, которые отрабатывают BGP fullview на линках в 40Gbit/s, 100GBit/s и далее, и имеют десяток пиров, 3-4 аплинка и десятки даунлинков. И к твоему огромному удивлению, это всё ещё Земля, а не другая планета

Всё, что я тут говорю, ориентируется на проблемы именно этих "ребят", потому что если они не будут успевать, то это ударит по всем, и ты не сможешь посмотреть субботним вечером фильм с нетфликса или что там у тебя будет источником.

SK>>>Это происходит в случаях плохого дизайна сети, когда архитектор заставляет раутер выполнять противоестественные функции другого устройства.
N>>Только что-то этот "плохой дизайн" происходит в подавляющем большинстве сетей, когда они не укладываются в гениальные задумки мудрецов из башен из слоновой кости.
SK>утренний стаканчик смузи не заменяет образования и опыта.

А теперь прошу высказаться по делу. Или не комментировать вообще.

SK>При таком подходе к проектированию и IPv6 и FFFF портов вместе взятые быстро исчерпаются.

IPv6 исчерпать сложно, а вот 16 бит на порты — тривиально.

Здравствуйте, Serginio1, Вы писали:

S> Спасибо буду знать. Я про то, что никто не будет просто чесать по всем адресам, будет алгоритм для как минимум бинарного поиска.
S> В твоем примере это деревья.

Да.

S> Shmj то пишет, что проблемы в процессоре. При бинарном поиске все эти затраты нивелируются

До какой степени они нивелируются?

Возьмём линк на 40Gbit/s, это нормальная скорость для провайдера мирового масштаба. Средний размер пакета очень плохо гуглится. Я считал 500 байт, но есть неясной авторитетности сообщения про 300 байт. Я готов поверить, потому что сейчас >90% трафика это видео. Возьму 500 байт. Получим 10 миллионов пакетов в секунду на таком линке. Предположим, что это один такой линк для одного процессора. Тогда у него 100 нс на всю обработку одного пакета. Возьмём половину из них на память и что мы смотрим только старшую половину IPv6 адреса — или даже что меньше /48 не смотрим (в смысле, префиксами длиннее), потому что даже PI не выдают дробнее /48. Тогда 6 байт на поиск в глобальном раутинге. Пусть у нас дерево побайтное. Получится 8 наносекунд на один шаг поиска, включая работу процессора. Оставим 5 нс на ожидание памяти.

Вот теперь начинается интересное. Для DRAM операция закрытия текущей строки и открытия новой в лучших современных образцах это 30 нс, а совсем недавно было нормально и 50 нс. DRAM — в топку, повторюсь уже в 4й раз в этой теме. Процессору нужно 64-128MB на IPv4+IPv6 fullview (и то не уверен, что я не пропустил какие-то важные детали, тогда ещё больше), и это всё static RAM. Ну, наверно, успеваем, если одно чтение из памяти отрабатывает за 1нс или меньше.

Теперь корректируем на 300 байт на пакет, на 100GBit/s линк (есть и такие уже), на рост таблиц BGP (при полном переходе на IPv6 его таблица минимум удвоится, если не дойдёт до миллиона, как сейчас с IPv4). Медленно охреневаем от числовых требований и понимаем, что без подхода типа "8 параллельных процессоров на каждой сетевой карте с полным объёмом данных в собственной памяти" это не работает. А я ещё не начал считать внутренние кросс-шины, сколько и как они должны пропустить...

Здравствуйте, netch80, Вы писали:

SK>>У нас, на планете Земля, как-то не принято пока ещё строить полносвязные сети "каждый с каждым". 1-2 редко 3-4 WAN аплинка на раутер, 1-2 редко 3-4 LAN. Таким образом таблица маршрутизации и ширина блока имеют разумную величину, не смотря на то что даже средний SOHO раутер может больше.

N>А они неинтересны в плане текущей дискуссии. Интересны те, которые работают под максимальной нагрузкой. А это те, которые отрабатывают BGP fullview на линках в 40Gbit/s, 100GBit/s и далее, и имеют десяток пиров, 3-4 аплинка и десятки даунлинков.

N>Всё, что я тут говорю, ориентируется на проблемы именно этих "ребят", потому что если они не будут успевать, то это ударит по всем, и ты не сможешь посмотреть субботним вечером фильм с нетфликса или что там у тебя будет источником.

На уровне fullview не оперируют одним конкретным IP адресом src/dst. (и не раутят весь свой трафик одной железкой).

SK>>При таком подходе к проектированию и IPv6 и FFFF портов вместе взятые быстро исчерпаются.

N>IPv6 исчерпать сложно, а вот 16 бит на порты — тривиально.

Опять же, порты не влияют на маршрут пакета.

В принципе ничто не мешает принять RFC расширяющий и дополняющий, с сохранением совместимости.

Все проблемы от жадности и глупости

Здравствуйте, netch80, Вы писали:

S>> Спасибо буду знать. Я про то, что никто не будет просто чесать по всем адресам, будет алгоритм для как минимум бинарного поиска.
S>> В твоем примере это деревья.

N>Да.

S>> Shmj то пишет, что проблемы в процессоре. При бинарном поиске все эти затраты нивелируются

N>До какой степени они нивелируются?

N>Возьмём линк на 40Gbit/s, это нормальная скорость для провайдера мирового масштаба. Средний размер пакета очень плохо гуглится. Я считал 500 байт, но есть неясной авторитетности сообщения про 300 байт. Я готов поверить, потому что сейчас >90% трафика это видео. Возьму 500 байт. Получим 10 миллионов пакетов в секунду на таком линке. Предположим, что это один такой линк для одного процессора. Тогда у него 100 нс на всю обработку одного пакета. Возьмём половину из них на память и что мы смотрим только старшую половину IPv6 адреса — или даже что меньше /48 не смотрим (в смысле, префиксами длиннее), потому что даже PI не выдают дробнее /48. Тогда 6 байт на поиск в глобальном раутинге. Пусть у нас дерево побайтное. Получится 8 наносекунд на один шаг поиска, включая работу процессора. Оставим 5 нс на ожидание памяти.

N>Вот теперь начинается интересное. Для DRAM операция закрытия текущей строки и открытия новой в лучших современных образцах это 30 нс, а совсем недавно было нормально и 50 нс. DRAM — в топку, повторюсь уже в 4й раз в этой теме. Процессору нужно 64-128MB на IPv4+IPv6 fullview (и то не уверен, что я не пропустил какие-то важные детали, тогда ещё больше), и это всё static RAM. Ну, наверно, успеваем, если одно чтение из памяти отрабатывает за 1нс или меньше.

N>Теперь корректируем на 300 байт на пакет, на 100GBit/s линк (есть и такие уже), на рост таблиц BGP (при полном переходе на IPv6 его таблица минимум удвоится, если не дойдёт до миллиона, как сейчас с IPv4). Медленно охреневаем от числовых требований и понимаем, что без подхода типа "8 параллельных процессоров на каждой сетевой карте с полным объёмом данных в собственной памяти" это не работает. А я ещё не начал считать внутренние кросс-шины, сколько и как они должны пропустить...

Опять же когда ты используешь деревья для поиска, то для понимания больше меньше, тебе не надо сравнивать полностью 16 байт. В большинстве случаев хватает и 8.
Только в конце поиска тебе придется полностью сравнивать.
Опять же посмотрим во сколько раз производительность процессоров и памяти выросла и количество ядер. При этом 64 битные процессоры массово появились относительно недавно.
И тоже крику было много. Однако живем и в мобильниках давно существует.