Opened 20 months ago

Last modified 19 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


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.


Change History (3)

comment:1 Changed 20 months ago by zzz

related: #698

comment:2 Changed 19 months ago by zzz

Status: newinfoneeded_new

Please point us to the file and line number or method in question

comment:3 Changed 19 months ago by jogger

Status: infoneeded_newnew

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...
        _maxSends = _pushCount;
        return rv;
Note: See TracTickets for help on using tickets.