Identical FORWARD_TSN sent repeatedly, as SACKs arrive over high-latency connections. #374
Description
Your environment.
- Version: A recent one I guess?
- Browser: Chromium for sure, maybe others too?
- Other Information - stacktraces, related issues, suggestions how to fix, links for us to have context
As discussed in discord.
pion-4213129707.log
What did you do?
I'm using a DataChannel with ordered=False, maxRetransmits=0 to send data from pion to chromium. My data exchange involves sending data at ~5Mbps over a link with a round-trip latency of ~30 ms. The data is sent in bursts, with a ~17 packet message sent ~30 times per second.
What did you expect?
A FORWARD_TSN at the end of every 17 packet burst, with a newCumulativeTSN matching the end of the packet burst.
Maybe an extra FORWARD_TSN or two, just in case the first one got lost.
What happened?
- The browser sends one SACK for every two DATA packets, so ~9 for the ~17 packet burst.
- pion sends a FORWARD_TSN for every SACK received, i.e. ~9 sends of the same FORWARD_TSN
- The browser implements rfc3758 3.6 which says
Note, if the "New Cumulative TSN" value carried in the arrived FORWARD TSN chunk is found to be behind or at the current cumulative TSN point, the data receiver MUST treat this FORWARD TSN as out-of-date and MUST NOT update its Cumulative TSN. The receiver SHOULD send a SACK to its peer (the sender of the FORWARD TSN) since such a duplicate may indicate the previous SACK was lost in the network.
and hence sends a SACK for each FORWARD_TSN received.
- Which means pion receives even more SACKs - meaning it produces even more FORWARD_TSNs