TCP overeager retransmission (IDFGH-14130)

[bryghtlabs-richard]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Sometimes(usually every 45-75 seconds but sometimes within a few seconds) during a WebSocket connection on ESP-IDF 5.1.2, the ESP32's TCP stack will send a TCP retransmission very quickly, well before the retransmission time-out should've fired. This then causes the server to emit a duplicate acknowledgement unneccesarily, and generally increases data transfer overhead:

Here are the relevant LwIP configurations I thought might be important:

CONFIG_LWIP_TIMERS_ONDEMAND=y
CONFIG_LWIP_TCP_RTO_TIME=500
CONFIG_LWIP_TCP_TMR_INTERVAL=250

I attach the others here: sdkconfig_lwip.txt

[bryghtlabs-richard]

Our RTT for this connection is approximately 35ms.

I haven't touched this layer of networking in a long time, it looks like the recommendation per-connection is now:

RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'| //Smooth abs(deviation from SRTT) into RTTVAR
SRTT <- (1 - alpha) * SRTT + alpha * R' //Smooth the RTT value into SRTT
RTO <- SRTT + max (G, K*RTTVAR) //Where K=4, G=ClockGranularity so RTO should be SmoothedRTT, plus max(clock-Granularity, 4x RTTVAR).

I think it's on me to record this again and try to compute values for RTTVAR and SRTT - perhaps our RTT is remarkably stable, so RTTVAR is close to zero?

[bryghtlabs-richard]

After rereading the RTO section of RFC, I didn't realize it's expected for newer TCP stacks could even compute an RTO so low, so perhaps these retransmissions may be expected?

I'm sorry to have bothered you about this, my knowledge was quite out of date.

[bryghtlabs-richard]

Hmm, updating sys_now() to use highres time instead of OS ticks seems it may help some. More testing needed.

u32_t sys_now(void) {
int64_t esp_timer_get_time();
return esp_timer_get_time() / 1000;
//return xTaskGetTickCount() * portTICK_PERIOD_MS;
}

[rsaxvc]

Perhaps an LwIP issue, or an ESP integration with LwIP issue. Odd that I can't seem to find how portTICK_PERIOD_MS is mapped to G ESP-IDF/components/lwip code, but that should only impact RTO once RTTVAR < portTICK_PERIOD_MS / 4, which shouldn't be the case here.