#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 он проверяется