search

private-octopus / picoquic

Minimal implementation of the QUIC protocol
MIT License
540 stars 159 forks source link

Wifi rtt spike #1484

Closed huitema closed 1 year ago

huitema commented 1 year ago

Add tests to understand what happens if the Wi-Fi channel gets "suspended", e.g., when the Wi-Fi card is performing a channel scan.

huitema commented 1 year ago

The "long" tests simulate wifi access link to cloud server, and show that BBR recovers from the spike less quickly than Reno or Cubic. The "datagram" tests use a setting similar to the long tests, and also show that BBR takes a long time recovering from the disruption. The analysis of traces shows that the estimated bandwidth climbs after the end of the spike. This is due to the sudden arrival of the packets delayed by the spike. Those packets are acknowledged immediately. The sender recognizes them as correcting a spurious retransmission, but adds the received bytes in the count of bytes "acknowledged in the epoch", which causes the bandwidth estimate for the epoch to be way to high. Next step is to fix that.

Correction: there are multiple issues, each listed separately. We will try fix them later.

huitema commented 1 year ago

Merging this PR without actually fixing the issues. Opened issues #1485, #1486, #1487 and #1488 to track those.