Opened 6 years ago

Closed 6 years ago

#1062 closed defect (fixed)

If initial RTT > initialRTO it never gets updated

Reported by: zab Owned by:
Priority: minor Milestone: 0.9.9
Component: streaming Version: 0.9.8
Keywords: rtt rto Cc: zab@…, zzz@…
Parent Tickets:

Description

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.

Subtickets

Change History (7)

comment:1 Changed 6 years ago by zab

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

comment:2 Changed 6 years ago by zab

  • Cc zzz@… added

comment:3 Changed 6 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.

ACK

comment:4 Changed 6 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 6 years ago by zzz (previous) (diff)

comment:5 Changed 6 years ago by zab

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 6 years ago by zab

Pushed to trunk in rev ad0ab5020bb253c5233ac2f036c0cf4f40001d51

comment:7 Changed 6 years ago by zab

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.