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

orignal короче давайте кратко чего тут без меня по поводу SSU2 надумали,

orignal вмержил изменения сэма

Vort только половину надумали - надо давать транзитным пакетам больше времени сидения в очереди (скорее всего без привязки к RTT, скорее всего около 4 секунд)

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

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

Vort так как цель - побыстрее донести информацию (сигнал) о перегрузке (переполнении), алгоритм использует смешанный подход:

Vort для транзитных пакетов сделан head drop, для своих - tail drop (так как о "потере" своего пакета есть возможность узнать сразу же)

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

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

NS Вопрос: какие параметры конфиг файла нужно прописать для узлов на статических ip c большой пропускной способностью, чтоб выжимать максимум пользы для сети? Порты какие нужно открывать?

Vort NS: прописать bandwidth = в соответствии с возможностями и поставить [limits] transittunnels = побольше

Vort порт открыть достаточно один, который в конфиге, но открыть его надо и по TCP и по UDP

NS bandwidth = Х пойдет? Или лучше какое то конкретное значение?

NS Цитата: порт открыть достаточно один, который в конфиге, но открыть его надо и по TCP и по UDP - это какой именно? Там портов куча в конфиге.

Vort NS: этот: github.com/PurpleI2P/i2pd/blob/f93b354c36ead7a0ccbeaa504ea8972f9dbe48f7/contrib/i2pd.conf#L69-L72

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

Vort пока нет атак, это не важно

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

Vort NS: ещё стоит подумать над настройкой floodfill =

Vort с одной стороны, поставить туда true - самое подходящее для мощных узлов

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

Vort NS: ещё один немного рискованный метод - это поднятие нескольких узлов на одном компьютере/IP адресе. для обычных узлов и для узлов флудфилов разрешенное количество различается

Vort лучше больше одного флудфила на IP адрес не ставить

NS По порту понял, по умолчанию 4567, но лучше чтоб польователь вручную сам что то придумал от 1024 до 65535. Можно ли этот конфиг с bandwidth = Х рекомендовать тем, кто за NAT сидит?

Vort 4567 - это не по умолчанию. по умолчанию рандомное значение, которое прописывается в router info если я правильно помню

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

NS 4567 - это не по умолчанию. Понял. Хорошо. Есть какие либо еще рекомендации?

Vort если у этих пользователей за NAT достаточная пропускная способность (> 2 мегабайт/сек), то стоит ставить X, да

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

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

Vort там сложная ситуация. условно говоря, причина недогруженности узлов за NAT - в багах и недоработках, как конкретно i2pd, так и протоколов i2p в целом

Vort ну и говоря про NAT я имею в виду ситуацию, когда невозможно полноценно принимать входящие подключения. если порт проброшен, то такой узел будет работать так же хорошо, как и без NAT

Vort NS: ещё стоит проверить состояние IPv6 сети. параметр ipv6 = должен соответствовать возможностям

Vort если у пользователя нормальный, прямой доступ через IPv6, то стоит ставить ipv6 = true

Vort если нету, то важно, чтобы стояло ipv6 = false. i2pd сам не сообразит

Vort NS: также стоит убедиться, что флаги у узла правильно проставились. для белого IP должно получиться Router Caps: XfR для флудфила и XR для не-флудфила

Vort если вместо R стоит U или если есть буквы D или E - значит, есть проблемы и надо разбираться

Vort правда, алгоритм определения R / U в i2pd часто глючит, в таком случае стоит нажать ссылку Router commands / Run peer test несколько раз

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

Vort если D или E - значит, узел перегружен. или по количеству транзитов или по трафику

Vort есть ещё флаг G, но он появляться при нормальной работе не должен

NS Ок. Чуть позже в личку скину, что у меня получилось. Спасибо!

orignal я думаю надо делать SSU2 логически близким к NTCP2

orignal в плане дропов пакетов

Vort orignal: почему не "наоборот" - дропы NTCP2 делать близкими к SSU2?

Vort то, что атакующие не заDoSили NTCP2, - это лишь показатель их лени

Vort тестовый бинарник с новыми стримами крешнулся

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

Vort может стримы виноваты, может ещё что-то

orignal а как их можно заддосить?

Vort кого их? NTCP2 транспорты? наполняя очередь

Vort то есть, отправляя быстрее, чем принимающая сторона может или хочет прочитать

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

orignal ну так и счас наполянют

Vort при нормальной работе это происходит случайно

Vort если несколько очередей наполнится - то не страшно

Vort атакующий же может постараться наполнить как можно большее количество

Vort потратив как можно меньше трафика

orignal а как их можно забить кроме как через тоннели?

Vort не совсем понимаю - какая разница через что забивать. важно то, есть такая возможность у атакующего или нету

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

Vort если контроллировать сколько сообщений принялось, то можно постараться не превшать лимит в 500 сообщений, чтобы Terminate() не словить

orignal ну там же размер очереди проверяется

Vort поэтому атакующему надо её не переполнять, а держать наполненной близко к лимиту

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

orignal можно еще по времени отравки смотреть

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

Vort ну вот потому я и делал оценку переполнения по времени "сидения" в очереди

orignal а я хочу просто

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

orignal делим на число байт и смотрим превышеат ли пороговое значение

orignal в соотвемтвии с заяленной скоростью

Vort это ты имеешь в виду измерения на TCP уровне?

Vort мы ж пока что обсуждали очереди из сообщений

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

orignal вызываем async_write

orignal потом когда приходит коллбэк смотрим сколько времени заняло

orignal посчитали скорость

orignal если она ниже заявленной узлом закрываем сессиию и все дропаем

Vort узел заявляет общую скорость, а так измерится скорость лишь одного из транспортов

orignal угу но все равно верхний предел будет верный

Vort можешь числа для примера показать? не могу пока понять идею

orignal надо подумать

Vort допустим, со стандартным bandwidth = L

orignal отправили буфер в 64K коллюбэк за 1 сек

orignal итого у нас скорость 64K в секунда

orignal если L то продолжаем

orignal если O то дропаем

orignal примерно так

Vort у O узла в тот момент могло быть 4 таких отправки в 64к за 1 сек, наша - одна из них

Vort да и наш узел тупить может по множеству причин

un orignal, здарова. нелели 2-3 как полеты стабильные, может ли быть связано с тем что жависты флудфил_ssu баг починили ?

orignal а что за баг был?

orignal Vort потому и надо подумать

un то что без ssu1 жава не становилась флудфилом

orignal надо считать как то более сложно

orignal вряд ли число флудфилов влияет на стабильность

segfault orignal: пиковая скорость может быть больше заявленной? например, 1 секунду передаём с максимальной скоростью, потом 10 секунд ничего не передаём. в среднем: L. такое будет недопустимо?

segfault orignal: такой вариант могу предложить: массив из 60 беззнаковых целых чисел. time() % 60-ый элемент хранит количество переданных байт в i-секунду. то есть циклически замкнутый. отдельной переменной переменной поддерживается сумма байт во всём массиве. за o(1)

segfault считаем среднюю скорость за минуту. если в какую-либо секунду средняя скорость за минуту превышает верхний порог: закрываем сокет

segfault orignal: можно не минуту сделать, а например 20 секунд

orignal отстань

orignal разговор не с тобой был

orignal onon дай снова ссылки на изменения

onon Ща поищу

onon privatebin.i2p/?0d3646084e5409fe#F18uirJZ7R2bEnh9d5EPKD5K2QbZuCz9TESmL64xKsYL

onon privatebin.i2p/?2a2cc457c97bc7e8#78ctT4skj7Lf6Ykgmua4ArvRx51Wx1fHs7fQiE3NCqk3

onon Я там наверняка сделал неэффективный код

onon Можно переписать/оптимизировать

orignal попробуй сегодня

orignal попробую

onon Я ж не програмист

orignal а что делает то?

onon Ну там немного другой алгоритм

orignal и что это дает?

onon Он на стоячей волне работает

onon Пытается выжать максимум из узкого места

onon За счёт того что создаёт там намеренно очередь

onon Небольшую

orignal ну так а что будет? быстрее рабоать? стабильнее?

onon Плюс срабатывание защиты загрубил

onon Поэтому на мелкие всплески RTT не реагирует

onon Поэтому продолжает слать с прежней скоростью

orignal вот так понятнее

onon А по поводу RTT и буферов щас распишу

onon Я так понял, Vort пытался сделать codel

orignal это что?

onon Это такой AQM

onon Типа "прогрессивный" RED

onon Если у нас в "узком месте" 100КБ/с, то теоретически, отправитель, разогнавшись до 200КБ/с, должен обнаружить рост RTT и сбросить окно.

orignal поглядим

onon Ты пока на стримы погляди, спрашивай, что непонятно пока я тут

onon А то могу скоро исчезнуть

onon В общем, если в узком месте пинг до следующего узла 100мс, то в таком случае задержка вырастет до 200

onon Но если мы возьмём общую задержку на маршруте в 1000мс

onon То общая задержка вырастет до 1100мс

onon Что вообще на уровне нормального "дрожания" RTT

onon Т.е. отправитель даже не заметит такой рост RTT

onon А чтобы он его заметил, необходимо значительное отклонение от минимального RTT

onon Это что касается Delay-based СС

onon Теперь по поводу Loss-based СС.

orignal мне счас некогда

orignal попозэе

onon Так как у нас в сети очень большие задержки, то дроп пакета промежуточным маршрутизатором создаёт большие проблемы для нас, так как получается HOLB

onon И все пакеты, отправленные после потерянного пакета будут копиться на получателе и ждать пока отправитель переотправит этот потерянный пакет

onon А это примерно 1,5 RTT

onon Поэтому мне сильно не нравится идея использовать loss-based алгоритмы

onon А с delay сами видите, какая история получается

orignal вот поглядим

onon Оптимальным мне пока видится обычный RED/WRED.

orignal Vort говорил у него с новым кодом грохнудось

onon Так как отправитель увеличивает размер окна в два раза за 1 RTT, а максимальный размер окна у нас сейчас 512, то за 1 RTT у нас может получиться 256 "лишних" пакетов.

onon Т.е. теоретически, если настроить RED на срабатывание при превышении очереди в 256 пакетов, то этого должно хватать для одного потока для полной утилизации ширины канала.

onon Примерно так сейчас у нас сделано в NTCP2

onon Только там не RED а скорее tail drop

onon После 250 пакетов

onon В будущем, конечно, хотелось бы увеличить максимальный размер окна для большей скорости

onon Тогда нужно будет и RED перенастраивать

onon Ну и тагов побольше сделать

onon И вообще сделать как-то согласование количества тагов на уровне сессии

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

onon Но у RED тоже есть очевидный недостаток - транспортов у нас могут быть тысячи

onon И каждый будет хранить по 256+ пакетов...

onon Может гибрид какой сделать...

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

onon Например равному максимально допустимому RTT

orignal ну короче будет работать быстрее?

onon Ну не всегда...

onon Но в основном да

onon В некоторых случаях может работать хуже чем нынешний

onon Но довольно редко

onon Самое главное, что он меньше шумит

onon Работает плавно по возможности

onon Но медленно разгоняется

onon Если транспорты переделать и подождать пока все обновятся, потом можно будет этот лимит выключить

onon И будет разгоняться быстро

orignal потестирую

onon Ты только сам код посмотри, а то может я там такого понаписал

onon Чего писать ненадо

orignal посотмрю

onon Оно там примерно вот так работает:

onon 6woqj4si4zc4j6gyie63qcpnenuy7c5nukket53ayoe4wo4a5naa.b32.i2p/chart12.png

onon 6woqj4si4zc4j6gyie63qcpnenuy7c5nukket53ayoe4wo4a5naa.b32.i2p/chart13.png