Opened 8 years ago

Closed 8 years ago

#1062 closed defect (fixed)

If initial RTT > initialRTO it never gets updated

Reported by: Zlatin Balevsky Owned by:
Priority: minor Milestone: 0.9.9
Component: streaming Version: 0.9.8
Keywords: rtt rto Cc: Zlatin Balevsky, zzz
Parent Tickets: Sensitive: no


If the RTT to a peer is really higher than initial RTO (9000ms) then all packets get resent and the RTT/RTO never get updated. Observed in i2psnark.


Change History (7)

comment:1 Changed 8 years ago by Zlatin Balevsky

A proposed fix that takes care of the very first ack: http://pastethis.i2p/show/5687/

comment:2 Changed 8 years ago by Zlatin Balevsky

Cc: zzz added

comment:3 Changed 8 years ago by zzz

I keep coming up with odd cases where this isn't sufficient (a step-increase in RTT after a steady-state period, for example) but now this seems to be a simple and decent fix that will catch most of the problems, and in particular the issue in the OP. It will of course generate too high a RTT/RTO for a low-delay conn where the first packet was dropped and retxed, but we will recover from that case normally as the RTT/RTO adjusts.

The new method receivedAck() is equivalent to getRTT() > 0, either way is fine, just pointing it out.


comment:4 Changed 8 years ago by zzz

I just saw this in snark (this is without the patch above):

[Connection 64LToQ/f7cGCA from R6c6 up 6m wsize: 1 cwin: 1 rtt: 0 rto: 2000 unacked out: 1 unacked in: 0 sent: 11 rcvd: 11 ackThru 9 maxWin 128 MTU 1730]

Yes it appears to be a really slow connection again. I don't know how the RTO got adjusted from 9000 to 2000? Oh, maybe because it was inbound and not outbound? Not sure. Don't have the original line from when I first saw it at 9000. But 2000 is much worse and makes the fix even more important.

edit: to be clear, I never saw this connection at 2000. The connection in the OP was 9000.

Last edited 8 years ago by zzz (previous) (diff)

comment:5 Changed 8 years ago by Zlatin Balevsky

This is something else, not an initial connection problem. 2000 is the minimum RTO, which means that this connection has sampled RTT and computed RTO at least once. So this second example is something completely different; maybe we have measured RTT to be zero or somehow negative or there is a bug in the RTT smoothing. Maybe we should add code to prevent updating with zero & negative RTT.

For now I will push the 5687 patch to trunk and keep an eye for zero RTT connections, possibly opening a separate ticket.

comment:6 Changed 8 years ago by Zlatin Balevsky

comment:7 Changed 8 years ago by Zlatin Balevsky

Resolution: fixed
Status: newclosed

Closing ticket, will keep an eye for 0-rtt connections

Note: See TracTickets for help on using tickets.