-
Notifications
You must be signed in to change notification settings - Fork 851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[core] Revise SND DROP logic #1910
Labels
Milestone
Comments
maxsharabayko
added
Type: Bug
Indicates an unexpected problem or unintended behavior
[core]
Area: Changes in SRT library core
Epic
labels
Apr 1, 2021
This was referenced May 18, 2021
This was referenced Jul 12, 2021
1 task
This was referenced Aug 31, 2023
Some results related to Ran tests to determine the RCV buffer size leading to a 0% packet drop. See PR #2815. 50 Mbps, 100 ms RTT, 25% packet loss, SRT latency 1.0 seconds.The target RCV buffer size recommended by the Configuration Guidelines is The value to recommend based on the results below is SRT v1.5.3
SRT v1.5.3 with PR #2815
SRT v1.5.3 with PR #2815 and
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
CUDT::checkNeedDrop(..)
function.Some contansts for further reference:
1. Dropping on Buffer Timespan?
Sender dropping logic is applied if the sender buffer timespan exceeds
drop_threshold_ms
.Instead, the delay of the oldest packet in the buffer should be used (
Tnow - OldestPacketTS
).At the same time, only packets older than
Tnow - drop_threshold_ms
are dropped by sender.See issue #898.
2. Congestion if timespan > 0.5 x latency
Sending is forced (ignores the output pacing) if the buffer timespan exceeds 0.5 x SRTO_PEERLATENCY.
If there is no packet loss, SRT sender holds a packet in its buffer for at least (RTT + 10ms).
If SRTO_LATENCY is configured below 2xRTT, SRT sender will always think there is congestion and will tend to ignore
SRTO_MAXBW
option (or any other output pacing).3. Dropping too early
It takes ~RTT/2 for a packet to reach the receiver. Then receiver may request a retransmission for
SRTO_RCVLATENCY
.Retransmission takes ~1xRTT.
The latest reasonable time for a receiver to request a retransmission would be (from sender's clock):
where RTT0/2 is the sender->receiver network delay at the time of connection.
Sender receives this request at
If RTT0 == RTT, dropping after
SRTO_RCVLATENCY + 20ms
is ok-ish.If RTT0 > RTT, then sender drops too early.
4. Receiver Handling of Drop Request
The drop request from the sender does not always have the message number, but most of the time it has the range of sequence numbers to drop. However, the receiver buffer drops packets only by message number.
See
CUDT::processCtrlDropReq(..)
.Related Issues
#713, #898, #1519. #1738, #2003
The text was updated successfully, but these errors were encountered: