Negative packet loss

[Eyal Arubas]

Using the getStats API, I'm sampling connection stats at certain intervals to calculate connection speed and packet loss per unit of time (x % packet loss per second, etc.).

The report has cumulative packets loss (per https://www.w3.org/TR/webrtc-stats/#dom-rtcinboundrtpstreamstats-packetslost).

So naturally I expect this number to monotonically increase. But sometimes it decreases, which creates a negative packet loss in my calculations.

What is the reason for this behaviour?

Is it because late packets eventually arrive and the browser takes them anyway, thus decreasing the reported number of lost packets?

This behaviour was observed with Chrome 51.

Thanks.

[Philipp Hancke]

you're probably hitting https://bugs.chromium.org/p/webrtc/issues/detail?id=5361

-- typically you can ignore the one negative value where things decrease.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/708324f7-2d35-4ddf-aa2d-5598fbc3b9a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eyal Arubas]

Thanks Philipp,

But in my case I'm not creating a new offer and there is no re-negotiation. The codec remains the same.

Eyal.

[Ray Wang]

I guess there should be packet disorder in your network.

You may just ignore the negative value.

在 2016年6月23日星期四 UTC+8下午5:49:12，Eyal Arubas写道：

[mparis]

Hello Eyal,
it usually happens due to packet disorder as Ray said.
This disorder can be cause by network conditions and in the case of the video because of retransmissions.

Take a look at [1], but taking into account that in the case of WebRTC there must not be duplicates because they are dropped when SRTP unprotecting.

Refs
[1] https://tools.ietf.org/html/rfc3550#section-6.4.1

   cumulative number of packets lost: 24 bits
      The total number of RTP data packets from source SSRC_n that have
      been lost since the beginning of reception.  This number is
      defined to be the number of packets expected less the number of
      packets actually received, where the number of packets received
      includes any which are late or duplicates.  Thus, packets that
      arrive late are not counted as lost, and the loss may be negative
      if there are duplicates.  The number of packets expected is
      defined to be the extended last sequence number received, as
      defined next, less the initial sequence number received.

[Jeremy Noring]

Stumbled across this when my SFU reported bogus values to WebRTC.

it's also worth nothing that WebRTC currently interprets all of these as unsigned values anyway (see report_block.h/.cpp, which defines cumulative_loss_ as a uint32_t), so regardless of what RFC3550 says, your best bet is to forbid negative values anyway.  Also the idea of negative packets lost is dumb (my opinion, of course).

Question: does WebRTC do anything with this field?  I can't see where it actually does much of anything with it, but the plumbing is kinda intense and I'm not positive.