zhekunren opened a new pull request, #19589:
URL: https://github.com/apache/nuttx/pull/19589
## Problem
The original condition `work_available(&conn->work) && tx_unacked != 0`
prevented `tcp_update_retrantimer` from being called when the work queue
was still busy, leaving `conn->timer` stale or zero. This caused the RTT
estimation to compute a false RTT (`m = rto - 0 = rto`), creating a
positive feedback loop that inflated the RTO to extreme values (e.g.,
232 half-seconds = ~116 seconds).
## Detailed Scenario
1. First send: `work_available` is true, the condition passes,
`conn->timer` is set to `conn->rto`, and the work queue is scheduled.
2. Second send (work still running): `work_available` is false, the
condition fails, `tcp_update_retrantimer` is not executed, and
`conn->timer` keeps its previous value.
3. Third send (work just fired but still unavailable): `work_available`
is still false, the timer is not reset; if the timer expires in the
meantime, `conn->timer` is decremented to 0.
4. ACK arrives: `conn->timer` is 0, so the RTT estimation computes
`m = rto - 0 = rto`, producing a bogus measurement.
## Fix
Remove the `work_available` check so that `tcp_update_retrantimer` is
always called when there is unacknowledged data. The decision to re-queue
the work is handled internally by `tcp_update_timer`. This ensures:
- When the ACK arrives, `timer` is always a freshly set value.
- `m = rto - timer` truthfully reflects the actual RTT.
- The bogus measurement caused by `timer = 0` is avoided.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
