id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,parents,sensitive
1939,I2CP: Poor loopback performace due to drops,zzz,zzz,"Large transfer from one local dest to another starts out fast but then stalls and proceeds very slowly. This is due to the router's i2cp transmit queue overflowing. Related may be that we don't return failure to the sender, see ClientManager.DistributeLocal.runJob(). Streaming is also to blame, doesn't recover quickly from large number of dropped sequence numbers, also built-in delays are far too large for loopback.
Fixes could be in router-side or client-side I2CP or in streaming:
- Client side doesn't know if dest is local, would it help if it did?
- Block instead of dropping on router side? Or would another queue just overflow?
- Return failure code via I2CP to sender?
- Reduce delays in streaming
- Improve recovery after massive drops in streaming, this is something we've worked on before, but not always successfully
While this is most apparent and easily reproducible with loopback, it could affect remote dests as well. This test was with a live router. Not sure if it also happens with LocalClientManager http://zzz.i2p/topics/1882 or if we use blocking there.",defect,closed,major,0.9.33,streaming,0.9.28,fixed,streaming,,,0