Added special container to collect loss stats. Added reorder stats #1219
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ethouris
added
[core]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #899.
The calculation of loss stats is given up to a separate container. The collection relies on the following rules:
The jump-over sequence is treated as MISSING packet - we don't know yet if it will turn out to be lost or reordered. It's then added to the container.
If a late packet (with sequence behind the current top) comes in, it's being "unlost" from the stats container so that it won't be notified as lost packet in the stats later.
When ACK is about to be sent, we state that all packets that didn't arrive so far, but have been fake-acked (dropped) can be treated as lost. Although it's possible in theory that a reordered packet has been received with a delay that exceeds the latency, this probability is negligible enough. Therefore at this moment all packets recorded as lost are treated as really lost, the loss statistics are updated, and records removed.
As precaution for a case that the stats loss container might swell out of control, there's a size limit also applied. If during adding it turns out that it would make the size exceed this limit, the oldest record is removed from the container. This record is not completely forgotten though (the size of the loss range will be still reported in the stats), just there's no longer a chance to qualify a packet in this range as reordered. The size is set as a half of the receiver buffer size, which should cover the biggest possible number of loss records.