~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@orignal
@postman
@zzz
%Liorar
%acetone
+FreefallHeavens
+Onn4l7h
+Sh0ck
+bak83_
+leopold
+r00tobo_BNC
+uop23ip
+xHarr
Arch
BeepyBee
BubbRubb
Danny
DeltaOreo
H20
Irc2PGuest16752
Irc2PGuest33667
Irc2PGuest97218
Maylay
Meow
ac9f_
anontor
b4dab00m
eyedeekay_
halloy13412
john231
makoto
nZDoYBkF
nilbog-
not_bob_afk
ntty
poriori_
profetik1
r00tobo[2]
shiver_
simprelay
solidx66
thetia
tr
u5657
vivid_reader56
zer0bitz
weko
zzz: What is reference for streaming protocol and realization?
orignal
basically what is it based on?
orignal
such NACKs is veru exotic thing
weko
I will do tests with UDP, but I guess most problems with speed in streaming protocol
weko
especially with SSU2 as transport
weko
streaming protocol or/and realization *
zzz
weko, orignal, streaming is all jrandom 2003, before my time
weko
Realization also?
zzz
what do you mean by realization? it's originally jrandom, but we've done a lot of fixes in 20 years
tennis2
Eye-eye peers, its me again. Re the above re above "i2psnark dropping all the metadata" (and re-reading disks) has anyone looked at the code, does it check out?
tennis2
If you like it and like the idea of not re-reading all the torrents on the disk it would be great if you might add it to your repo, with the above sudo command to autostart it.
orignal
zzz but maybe you know what was the underlying protocol
orignal
the questuion is why special protocol was required rather than ordinary TCP?
zzz
orignal, weko i2p-projekt.i2p/en/docs/api/streaming see history section at bottom
zzz
the full streaming implementation was deployed with a sliding window protocol and optimizations to take into account the high bandwidth x delay product.
zzz
some reasons:
zzz
dest vs. IP; 0-RTT delivery; signatures
zzz
you would have to write a user-mode TCP impl even if you did TCP
zzz
you can find a lot of the 2004-2005 discussion in the gmane.network.i2p newsgroup at NNTP news.gmane.io
zzz
you can either load it up in thunderbird or I might have a tarball somewhere
zzz
found it
zzz
^^^ orignal weko
orignal
yes I'm reading
orignal
I know I have to implement own TCP but it ould be a strdard thing
orignal
in our opinion NACKs cause a lot of inefficiency
weko
I don't know about nacks
weko
But I guess most problem is streaming. As I said, I will test with UDP
orignal
every time we receive a NACK it produced severe speed degradation
zzz
orignal, weko, I have some advice if you're working on streaming
zzz
don't do it on testnet (at least not at first) - it's too messy, too hard to get reproducible results
weko
[15:56:53] <zzz> don't do it on testnet (at least not at first) - it's too messy, too hard to get reproducible results
zzz
you want to do standalone loopback tests
weko
Ye I know
zzz
i2ptunnel client to server
zzz
and use wget or curl on a big file
weko
But some bugs we can see even at testnet
zzz
but you have to put delay and drop in the middle, you have to write that code if you don't have it
zzz
test say 100ms to 45s delay, and 0 to 10% drop
weko
zzz: I used wget, but wrote special tool
zzz
keep careful records, make charts or graphs of bandwidth vs. delay and bandwidth vs. drop
zzz
change only one thing at a time
zzz
look for how fast it recovers from stalls or if it gets "stuck" at a low bandwidth
zzz
also track retransmission % and window size trends
weko
I guess best way to repeat TCP algos
weko
But TCP doesn't have NACKs
zzz
right. the RFC I gave you the other day is important
weko
And for i2p we can do multipath
zzz
acks and nacks is the same thing, don't let it confuse you. nacks just tells you where the "holes" are
weko
I need more research
zzz
yeah we spent years on it. Don't make quick changes; test test test before checking anything in
zzz
if you can go i2ptunnel-streaming-i2cp you could use my i2cp loopback tester so you don't have to write anything... but I don't think you support streaming to i2cp?
weko
Why window size maximum is 128?
weko
I guess you have better implemention than i2pd, then why so low window?
zzz
don't know, but that's really big
weko
Nope
zzz
what's our max bytes? 1815? that's 232KB in flight
weko
Just calc speed for typical i2p 3+3 ping - 500ms, and with mtu
zzz
sure but you have to send 232KB w/o any loss to hit 128 window
zzz
what window sizes are you seeing on testnet?
weko
Maximum 400KB/s with 500ms ping
zzz
with no drop?
zzz
but what's the window size
weko
[16:10:54] <zzz> with no drop?
weko
Ye i2pd can
zzz
and RTT and RTO
weko
zzz: I set 4096 maximum, and saw it
zzz
I doubt it, that's 7.5 MB in flight
zzz
you shouldn't be buffering that much in the routers anyway
zzz
add 0.5 or 0.25% drop to get a more realistic test
weko
Okay for 500 ping and 14MB/s
weko
zzz: I added
weko
1%
weko
Can test more
zzz
500 round trip or per hop?
weko
So it works only with ntcp2 because bad steaming realization
weko
zzz: round trip
zzz
ok
weko
So unrealistic on real net
weko
But 128 really to small
weko
Too
zzz
disagree. 128 is fine in real world.
zzz
you can't send 7.5 MB at once, nobody has a buffer that big, it will all get dropped along the way
weko
zzz: when routers can give to us 1MB/s, we have only 400KB/s
weko
So I just suggest increase to 256
zzz
there's a lot of overhead
weko
But I know I need note tests etc
zzz
if you're going to 4096, you probably have bugs. It shouldn't go that high
zzz
are you doing AIMD?
weko
zzz: I agree about 4096
zzz
you need proper AIMD algorithms
zzz
the goal is not only to go fast. you also have to be _efficient_. you can't retransmit or nack like crazy
weko
What is AIMD
weko
All In Mind?
weko
We don't use AIMD
zzz
when you get a nack, cut your window in half
zzz
actually, now we cut it to one I think
zzz
you have a LOT to fix then
weko
I know)
zzz
this is basic stuff
weko
Agree
weko
Anyway window 128c can sometimes limiting i2p speed rn
weko
128*
zzz
ok, but once you do AIMD it won't be a problem
weko
With bad rtt but good bandwidth
zzz
actually we are now using TCP Westwood+ algorithms everywhere
weko
Hmm
zzz
we spent about a year converting everything to Westwood+
zzz
and fixing our timers
zzz
here's the references from our javadocs"
zzz
**
zzz
* A Westwood+ bandwidth estimator with
zzz
* a first stage anti-aliasing low pass filter based on RTT,
zzz
* and the time-varying Westwood filter based on inter-arrival time.
zzz
*
zzz
* Ref: TCP Westwood: End-to-End Congestion Control for Wired/Wireless Networks
zzz
* Casetti et al
zzz
* (Westwood)
zzz
*
zzz
* Ref: End-to-End Bandwidth Estimation for Congestion Control in Packet Networks
zzz
* Grieco and Mascolo
zzz
* (Westwood+)
zzz
*
zzz
* Adapted from: Linux kernel tcp_westwood.c (GPLv2)
zzz
*
zzz
* @since 0.9.46
zzz
*/
weko
Oh then we know reference
weko
It's good
zzz
if you are hitting 4096 window with 500 ms ping and 1% drop, you are very very very broken. You should be more like 20 window size for that
weko
zzz: yes I know. But I had 0% drops at tunnel layer
weko
I understand about what you
zzz
right, that's why you need to test standalone so NTCP2 or SSU2 don't "fix" the drops for you
zzz
because the java routers in the network do a LOT of dropping, so you either need java routers in your testnet, or a standalone test
zzz
a java router is not going to buffer 7.5 MB
weko
zzz: i2pd also drops
weko
Packet permutations is problem for i2pd rn
weko
Happens in ssu2 with i2pd and I guess with ntcp2 and ssu2 in java
weko
I really need sleep... with, in... Damn
weko
zzz: transits not necessary to have such buffers
zzz
you also have to be efficient. a TCP ack is 40 bytes. A streaming ack is 1028 bytes thru a tunnel. you can't be sending acks and nacks like crazy
zzz
what router bandwidth limits are you using on the testnet?
zzz
you may also wish to use i2psnark standalone in debug mode to see what our typical window/RTT/RTO/etc. values are