#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

orignal onon так как коммит назвать?

onon А ты что, решил такое заливать?

onon Ворт же сказал крешится

onon Но у меня не крешилось

onon Хз

orignal так он не знает крэшится это или нет

orignal вот зальем и проверим ))

onon Ну основное там это disable loss-control наверное

orignal и что вместо него?

onon Delay-based control

onon Там были оба вместе

onon Я щас улучшил делай и выключил лосс

onon Но лосс можно обратно включать кто хочет

orignal понял

onon Будет работать

orignal завтра залью

onon Но это не окончательный вариант, там ещё нужно переделывать кой-чего. Но я пока не в силах.

orignal ну в релиз можно запускать?

onon Оно работает лучше чем то что есть сечас

orignal отлично

onon Ну я долго тестил-гонял

onon Новых багов не обнаружил

orignal разберемся ))

onon Только дед может начать ругаться

onon Я не знаю точно как ява ограничивает скорость транзита

onon Если дропами - то им не повезло

orignal на деда покластб

onon Потому что этот алгоритм игнорирует бропы

onon Кроме choked

orignal счас закоммичу

onon Ну и нужно тогда начинать думать как нам самим ограничивать транзит тогда

onon Потому что один такой стрим примерно мегабайт/сек гонит

orignal ээээ

onon А то кто-то поставит себе лимит в 500кбайт/с а ему мегабайты будут гонять

onon И ничего он не сделает

onon Только новый туннели принимать перестанет

orignal ну это вообще другая тема

orignal у меня вот счас через ygg-only ротуер мег транзита прет и че?

orignal закоммитил

onon Да ниче, просто бывают лимитированные тарифные планы

orignal пусть L ставит

orignal тогда через него клиентские тоннели не буду строиться

orignal если явно не указать

onon Логично

onon Но это мягкий лимит

onon Нужно будет делать хард лимит

onon С задержкой пакетов

onon Чтоб не отправлял быстрее, чем в конфиге указано

onon А возможно и на приём ограничивать скорость

Vort "<@onon> Я так понял, Vort пытался сделать codel" основная цель была - защита от атаки, которую я описал ранее. но алгоритмы похожи получились, верно

Vort "<@onon> Т.е. отправитель даже не заметит такой рост RTT" поэтому мы и обсуждали перенастройку констант. если отправитель и 4 секундный лаг не заметит, то тут уже проблема в отправителе

Vort "<@onon> А с delay сами видите, какая история получается" получается, что не получается обсуждения. в первую очередь, нужно потдтверждение или опровержение возможности той атаки, что я написал

Vort затем подтверждение или опровержение эффективности того алгоритма что сейчас в SSU2 по противодействию этой атаке

Vort для альтернативных алгоритмов тоже можно сделать анализ, как по защищённости от атаки, так и по граничным условиям для дропа пакетов

Vort "<@onon> Только там не RED а скорее tail drop" там Terminate ()

Vort "<@onon> Тогда нужно будет и RED перенастраивать" это то, о чём я уже несколько лет как говорю - для разных скоростей нужны разные размеры буферов. поэтому в SSU2 и сделан лимит по времени. он учитывает эту особенность

Vort "<@onon> Чтобы пакеты удалялись, если больше максимально допустимого периода времени лежат." именно это и сделано

Vort осталось только константы до конца обсудить, но обсуждение опять ушло куда-то не туда

Vort onon: если скорректировать максимальное время сидения в очереди для SSU2, какие-то ещё проблемы у этого алгоритма останутся? если да, то какие?

onon > если отправитель и 4 секундный лаг не заметит, то тут уже проблема в отправителе

onon Согласен

onon > нужно потдтверждение или опровержение возможности той атаки, что я написал

onon Подтверждаю, атака на переполнение возможна

onon > подтверждение или опровержение эффективности того алгоритма что сейчас в SSU2

onon Очень эффективен. Настолько, что у нас в сети транзита почти не осталось.

onon > это то, о чём я уже несколько лет как говорю

onon И не ты один, сетевики уже десятки лет над этим думают

onon > какие-то ещё проблемы у этого алгоритма останутся?

onon Он перестанет защищать от вышеописанной атаки

onon И ещё. Обычный codel уже никто не использует. Все используют fq_codel

onon Но как это реализовать у нас, я точно не знаю.

Vort "<@onon> И не ты один, сетевики уже десятки лет над этим думают" у сетевиков немного другая задача, да и лимиты по доступным ресурсам более жесткие

onon Должен быть общий какой-то буфер для всех транспортов

onon И там уже для каждого потока рассчитывать время

onon Так буфер может быть больше, но переполнение не получится

Vort "<@onon> Он перестанет защищать от вышеописанной атаки" предлагаю подобрать более чёткие доказательства. я считаю, что при 100мегабитной сети максимальное потребление RAM очередью будет 44 мегабайта при 4 секундном лимите

onon Я такое Лосю задвигал, он сказал подумает

Vort при лимите в 500 пакетов как в NTCP2 атака около полугига может выжрать (точно не рассчитывал)

onon 44 мегабайта это тоже много

Vort ну вот если сравнивать атаку при лимите по количеству и при лимите по времени, то при лимите по количеству шанс заDoSить узел раз в 10 выше

onon СОгласен

Vort "<@onon> 44 мегабайта это тоже много" для сценария атаки - не много. при обычном режиме работы такого быть не должно

onon Ты ещё что-то писал про head drop. Как это у тебя сделано?

onon Если у нас в буфере есть пакет с превышением, начинаем дропать начало очереди?

onon Звучит странно

onon И сколько пакетов из начала очереди дропаем? Все?

Vort через задницу сделано если честно. сейчас ссылки подыщу

onon Вот берём мы пакет, проверяем, есть ли в очереди пакеты с превышением - ага, - есть. Дропаем.

onon Берём следующий пакет - ага, -дропаем...

onon И так всю очередь?

Vort bool SSU2Session::SendQueue ()

Vort msg->GetEnqueueTime() + m_MsgLocalExpirationTimeout < mts

onon Ты мне на пальцах объясни

Vort head drop происходит при вынимании из головы очереди

Vort если вынули старьё - выкидываем

Vort у каждого пакета есть таймстамп

Vort он проверяется

onon Так это работает только если все пакеты старые?

onon Почему тогда head drop называется?

onon Если всё дропается

Vort какой старый - такой выкинется. какой не старый - отправится

Vort не всё

Vort только старьё

Vort потому что в голове самые старые пакеты. в хвосте могут быть посвежее

onon Странное утверждение

Vort ну проверь

Vort если все пакеты свежие - ничего не дропнется

Vort если все старые - всё дропнется

Vort если часть свежих, часть старых - старые дропнутся, свежие пойдут в отправку

onon Так это не head drop

onon Это просто ты проверяешь время перед отправкой

onon Запутал меня

Vort очередь естественным образом отсортирована по старости пакетов

Vort те, что в голове - просидели в очереди дольше, чем те, что в хвосте

Vort а так как забираем пакеты начиная с головы - то и получаем head drop

Vort ну можно называть этот алгоритм и как-то по другому, не суть

Vort посмотри лучше сам код

onon Я понял

onon По константам, думаю, для транзита можно попробовать 2 сек, для своих - 3 сек.

onon Этого должно хватать для нормальной длины тоннеля.

onon А у кого длиннее - потерпят.

onon Ну или 3 и 4...

onon Точно нужно тестировать

onon Если вопросов больше нет, я пойду дальше спать.

Vort тут вопрос в обработке "своих" дропов

onon Ты говорил, есть маркер

onon Если нет - просто один лимит на всех

onon Просто смысла нету делать для своих пакетов более жёсткий лимт

onon Тебя перегружают, а ты свои собственные пакеты дропаешь

onon Нонсенс

Vort я просто не знаю, доходит ли до стримов нормально информация о "своём" дропе

onon До стримов теперь информация нио каких дропах не доходит

onon Он их просто игнорирует

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

Vort но если это мы сами его специально перегрузили - тогда таки нонсенс

Vort вполне возможно, что для других типов пакетов это и правильно - мгновенно обнаружили затык и сунули пакет куда-то в другое место

Vort а для стримов нужно что-то другое

Vort но дело в том, что эту систему продумывал orignal и я плохо понимаю, что там зачем нужно

Vort я старался просто сделать так, чтобы ничего в ней не ухудшить

Vort а насколько она изначально было правильно спроектирована - этого я не знаю

onon Там ещё проблема есть, что у нас узел проверяет есть ли очередь на транспорте, и если есть, записывает этот роутер в профиле как "плохой"

onon Есть такое? Или мне показалось?

onon Так у нас все узлы плохими будут

onon isSlow врде так

Vort подробностей не помню, но если узел на время переполненной очереди исключится из выбора для туннелей - то и хорошо

Vort скорее всего после того как очередь рассосётся, то статус узла снова станет нормальным

onon Если на короткое время - то да

Vort перегрузить все очереди - это какая-то фантастика на данный момент

Vort сейчас чаще всего перегрузок или нет вообще или одна-две на несколько тысяч узлов

onon Это твоя защита так работает

onon Транзит в ноль режет

Vort так их и на NTCP2 нету

onon Потому что на пути в маршруте есть роутер i2pd с ssu2

onon =)

Vort их и до этого алгоритма не было

onon Потому что тогда и стримов быстрых не было

Vort причина в другом - процент активных транспортов всегда невелик

Vort основная масса транспортов обслуживает пинги

Vort поэтому массовой перегрузки очередей не может быть в принципе

Vort вот у меня сейчас 3 тыщи транспортных соединений. очередь только на 2 из них (0.07%)

Vort даже если очередей станет в 100 раз больше - 7% - это всё равно никак не повредит алгоритму выбора узлов для туннелей

onon Хоршо

Vort поискал я по коду onDrop и, похоже, что стримы этот механизм не используют. то есть, пакеты стримов дропаются по тому же принципу, что и транзитные

Vort то есть, для исправления проблемы достаточно в функции bool SSU2Session::SendQueue () поменять m_MsgLocalExpirationTimeout на 4000000

Vort onon: если будет возможность, проверь, поможет ли описанное выше изменение от проблемы с дропами, которую ты обнаружил

orignal не используют так можно же добавить

orignal но смотри в чем проблема

orignal стримы они ведь не сообщения отсылают а блоки чеснока

orignal тогда придется OnDrop привязывать как то к блокам

Vort по вот этой фразе я так понял, что добавлять не надо: "<@onon> Просто смысла нету делать для своих пакетов более жёсткий лимт"

orignal у меня более практический вопрос

orignal отключаем постквантовую криптографию для релиза или нет?

Vort ты же говорил что там что-то с zzz надо дообсуждать

Vort без понятия в каком состоянии этот процесс

Vort и в целом меня эта постквантовость не сильно интересует. не будет крешить, не будет дырок - и ладно

Vort особенно после срача с D-Wave

orignal то то и оно что в недоделанном состояннии

orignal думаю перед релизом отключить

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

Vort onon: я имел в виду те синтетические тесты, на которых ты обнаружил проблему

Vort если с ними всё в порядке, то и с реальными сценариями всё должно быть ок

Vort так как изменение там тривиальное

Vort можно, конечно, это изменение как-то аккуратнее оформить, но не хотелось бы опять встрять в долгую дискуссию

Vort самое главное - починить самое главное

onon А дропы можешь сделать рандомными, а не пачкой?

onon Пачкой - это очень плохо

orignal ты про OnDrop для стримов?

orignal там можно приделать его к чесноку и в лямбду передать какие номера пакетов там

orignal например

segfault orignal: что за постквантовое шифрование? есть официальный пропозал?

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

onon А нужно бы дропать вероятностно в зависимости от перегрузки в данный момент

onon И вообще не очень понятно как это работает с одиночными пакетами. Вот пришёл мне TBM, я запрашиваю через интродьюсера следующий хоп, соединяюсь, и...

orignal сколько дропать?

onon Blinded message

onon Потому что он долго ждал пока я соединюсь?

orignal сколько долго?

onon Ну 500 мсек например

orignal перед соединением там вообще другая очередь

orignal а вот после соединения когда мы делаем splice это интересно

orignal проверяем ли мы время

orignal а вот по уму не надо дропать а высрать все сразу

orignal короче для новой сессии дроп через 4 секунды

orignal поставил новые стримы где радио

onon И что, работает?

orignal да

orignal проверь сам

segfault onon: можешь хоть ты ответить?

onon На что?

segfault onon: orignal: что за постквантовое шифрование? есть официальный пропозал?

onon Историю чата читай, я так не помню

onon Пропозал есть

segfault onon: был оффлайн. кинь ссылку на i2p-projekt.i2p, если не сложно

onon i2p-projekt.i2p/spec/proposals/169

orignal нафига дал ссылку?

orignal чтобы он еще и тут лез со своими "суждениями"?

segfault onon: спасибо

Vort "<@onon> Пачкой - это очень плохо" в случае 4-секундного затыка проблема будет совсем не в пачке. это будет скорее значить что узел просто ушел в оффлайн

Vort если такая хрень начнёт происходить, то её надо будет первым делом изучить, а потом придумывать меры противодействия

Vort "<~orignal> проверяем ли мы время" именно поэтому я сделал время постановки в очередь отдельным значением

Vort нет транспорта - нет очереди - нет времени постановки в очередь

onon Ты вставляешь в очередь пакеты пачкой. И всем пишешь одно и то же время, разве нет?

onon И потом ты эту всю пачку дропаешь

orignal нет

orignal ьам время создания I2NP сообщения вроде

Vort он правильно пишет

Vort только вот этого "потом" не должно происходить

Vort не должно быть дропов

Vort не должно быть расжиревания очереди до 4 секунд

Vort это всё лишь защита от атаки

orignal а ну да в момент вставки

Vort а в случае атаки там будет пофиг пачка или не пачка

onon Тогда может хотя бы меньшими пачками вставлять?

onon Если рандом дроп сделать не можешь

Vort в NTCP2 так вообще Terminate. по-моему, проблема поважнее

onon Ну да, там хотя бы RED сделать нужно

Vort дело не в том, могу или не могу, а в том, что нужны качественные тестовые кейсы. чтобы можно было оценить эффект

Vort пока что я видел разрастание очередей только от ухода узлов в оффлайн

Vort если хочется дальше улучшать это место, то я считаю стоит для начала сделать изменение на 4 секунды, а затем наблюдать

Vort если будут заметны переполнения, то надо будет попытаться понять, почему так произошло

onon Потому что ява на дропах работает

onon Она будет растить окно пока дроп не получит

Vort там ещё есть одна особенность - по-хорошему, дроп с головы надо делать не только в момент отправок, но и при постановке в очередь. но это вопрос будущего

onon Каноничный клиент не так страшен, там 128 окно

Vort я как обычно не хотел ничего поломать (а ещё и затормозить), поэтому оставил как было

onon А дрозд там себе 512 вроде поставил

onon ВОт он и будет перегружать

Vort не значит ли это что им тоже надо бы переходить на анализ задержек?

onon Конечно надо бы, но там есть проблемы

Vort ну и нужно экспериментальное подтверждение. может там у них из-за багов никогда не будет такого разжиревания

Vort или всё же где-то стоит защита от такого

onon У явы есть RED

onon У нас нету

onon Для защиты от переполнения ява просто лимитирует количество транспортов

onon Оптимально было бы , конечно, выработать единую стратегию

Vort от переполнения непосредственно на их узле? мы о другом говорим

Vort о том что они транзитом могут у нас раздуть очередь

Vort да вот только на практике я такого не видел. поэтому нужно подтверждение

onon Ну вот я и говорю, что ява сама себя от такого защищает REDом

onon А наш NTCP2 вполне модет перегрузить

Vort может для начала отладим на SSU2 нормально?

onon До стадии "нормально" я думаю ещё далеко

onon Для начало хоть как бы

Vort тут видимо без быстрых стримов просто не будет толком тестовых кейсов

Vort мне не нравится идея писать код вслепую

onon Ну вот и посмотрим, как обновятся все

onon Будем подстраиваться

Vort надо только не забыть 4000000 поставить до релиза

Vort ну и оттестировать. я то думаю, что всё ок будет. но лучше получить подтверждение

Vort ещё это загадочное повреждение кучи. самая противная проблема

Vort я то думал или сразу крешнется или вообще никогда. а оно вон как. через 2 дня

onon Ну я пол года их по всякому гонял с разными параметрами, у меня ни разу не падало

onon Может от системы зависит

Vort запросто. но система или нет, баг есть практически гарантированно

onon Там расчет джиттера накоплением считается

Vort просто некоторые системы могут его игнорировать

onon Он в инт64 сумму добавляет а потом делит на количество

Vort и что? при чём тут куча?

onon Ну это всё что отличает эти стримы от старых

Vort ладно. если больше ни у кого повреждение не вылезет, то и пофиг

Vort может я когда-то потом погоняю с отладкой

onon Ну вон Лось на радио накатил, тестирует

Vort окей

onon У меня пока полтора часа работает

orignal не тестирует

orignal лось занят домашними делами

onon Роутер работает?

onon Не падает?

onon Значит тестирует...

Vort ага. у меня крешнулось само по себе тогда

Vort из нагрузки только этот чат был

Vort ну и транзиты понятное дело

orignal короче дед сказал что они релизят без посткватновой криптографии

Vort не знаю насколько это важно, но решил написать своё наблюдение:

Vort я за последние несколько дней несколько раз перезагрузил свой узел

Vort до перезапусков рейт был около 30%, после одного перезапуска стал около 40% (почти рекорд). ещё один перезапуск - 20%

Vort на атаки не похоже, выглядит как проблемы с балансировкой нагрузки

Vort но непонятно и откуда они берутся и почему они такие масштабные

Vort транзит 1-2 мегабайта/сек как был, так и остался

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

Vort хотя вот сейчас глянул график коннектов и вижу всплеск около 12 ночи по UTC. может, в этом дело

Vort хм. Transit: 125.10 GiB (4080.79 KiB/s)

onon Что, 4 сек поставил?

Vort нет, я на версии 2.56.0-123-gf93b354c

Vort без модификаций

onon Китайцы транк собрали

onon И торренты качают

Vort вот я тоже подумал, что кто-то может тестировать

onon Я вот радио лосиное слушаю

onon Уже 6 часов

onon 900 мегабайт накачал

orignal без обрывов?

onon Ну затыки бывают при переключении маршрута

onon А так непрерывно

onon Уже 7,5 часов

orignal ну неплохо