Opened 15 months ago
Last modified 14 months ago
#2641 new defect
RTT/RTO calc seriously flawed
Reported by: | jogger | Owned by: | zzz |
---|---|---|---|
Priority: | major | Milestone: | undecided |
Component: | router/transport | Version: | 0.9.42 |
Keywords: | Cc: | ||
Parent Tickets: | Sensitive: | no |
Description
The RTO/RTT calc is based on state.getLifetime(), which uses _startedOn. In case of NO_BW the waiting time adds to rtt instead of starting a measurement at start of actual transmission. Critical in my eyes as used for router steering including ACKing.
Can easily be seen from /peers where many reliable peers up for hours show high rtt/rto. This is self enforcing, as higher rtt mutually slows down ACKing on both ends. Also more significant after #2505 which forces the current send window to fill up completely, then completely using it up, possibly adding more than 1 sec to the rtt of the following messages.
Subtickets
Change History (3)
comment:1 Changed 15 months ago by
comment:2 Changed 14 months ago by
Status: | new → infoneeded_new |
---|
Please point us to the file and line number or method in question
comment:3 Changed 14 months ago by
Status: | infoneeded_new → new |
---|
There a some ways to fix this at different places. Currently as a quick hack I reset those within OutboundMessageState?.java at push(). So the timer starts when the message is actually sent.
public synchronized boolean push() { boolean rv = _pushCount == 0; if (rv) { _startedOn = _context.clock().now(); _expiration = _startedOn + EXPIRATION; } // these will never be different... _pushCount++; _maxSends = _pushCount; return rv; }
related: #698