Prevent BWE rampdowns without new loss reports.

webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc

Index: webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
diff --git a/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc b/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
index 02103716000649a333aca31b5ad5e24fd562f1fd..4bc8fffe33a43462b8dffc341cf3388f722ead7c 100644
--- a/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
+++ b/webrtc/modules/bitrate_controller/send_side_bandwidth_estimation.cc
@@ -49,7 +49,8 @@ SendSideBandwidthEstimation::SendSideBandwidthEstimation()
       min_bitrate_configured_(kDefaultMinBitrateBps),
       max_bitrate_configured_(kDefaultMaxBitrateBps),
       last_low_bitrate_log_ms_(-1),
-      time_last_receiver_block_ms_(0),
+      has_decreased_since_last_fraction_loss_(false),
+      time_last_receiver_block_ms_(-1),
       last_fraction_loss_(0),
       last_round_trip_time_ms_(0),
       bwe_incoming_(0),
@@ -58,8 +59,7 @@ SendSideBandwidthEstimation::SendSideBandwidthEstimation()
       initially_lost_packets_(0),
       bitrate_at_2_seconds_kbps_(0),
       uma_update_state_(kNoUpdate),
-      rampup_uma_stats_updated_(kNumUmaRampupMetrics, false) {
-}
+      rampup_uma_stats_updated_(kNumUmaRampupMetrics, false) {}
 
 SendSideBandwidthEstimation::~SendSideBandwidthEstimation() {}
 
@@ -121,17 +121,16 @@ void SendSideBandwidthEstimation::UpdateReceiverBlock(uint8_t fraction_loss,
     accumulate_expected_packets_ += number_of_packets;

[mflodman, 2015/10/22 07:06:58]

Old, but I'd like to change name on this variable, to me accumulate(d) sounds
more like number of packets from the start. Can we change to something like
since last?

[pbos-webrtc, 2015/10/22 13:16:06]

Done.

[mflodman, 2015/10/22 14:34:34]

Thanks!

 
     // Report loss if the total report is based on sufficiently many packets.

[stefan-webrtc, 2015/10/22 09:20:47]

Maybe change this comment to explain the if-statement and not what comes after
it.

[pbos-webrtc, 2015/10/22 13:16:05]

Done.

-    if (accumulate_expected_packets_ >= kLimitNumPackets) {
-      last_fraction_loss_ =
-          accumulate_lost_packets_Q8_ / accumulate_expected_packets_;
-
-      // Reset accumulators.
-      accumulate_lost_packets_Q8_ = 0;
-      accumulate_expected_packets_ = 0;
-    } else {
-      // Early return without updating estimate.
+    if (accumulate_expected_packets_ < kLimitNumPackets)
       return;
-    }
+
+    has_decreased_since_last_fraction_loss_ = false;
+    last_fraction_loss_ =
+        accumulate_lost_packets_Q8_ / accumulate_expected_packets_;
+
+    // Reset accumulators.
+    accumulate_lost_packets_Q8_ = 0;
+    accumulate_expected_packets_ = 0;
   }
   time_last_receiver_block_ms_ = now_ms;
   UpdateEstimate(now_ms);
@@ -186,7 +185,7 @@ void SendSideBandwidthEstimation::UpdateEstimate(int64_t now_ms) {
   }
   UpdateMinHistory(now_ms);
   // Only start updating bitrate when receiving receiver blocks.
-  if (time_last_receiver_block_ms_ != 0) {
+  if (time_last_receiver_block_ms_ != -1) {

[mflodman, 2015/10/22 07:06:57]

I'd like to discuss if we should check already here or not.

[stefan-webrtc, 2015/10/22 09:20:47]

Are you talking about whether we should check for a receiver report before we
allow any ramp-up to start (current behaviour), or whether we should only allow
a ramp-up when receiving a new receiver report?

Current behavior is to ramp-up in small steps over a receiver report interval.

[mflodman, 2015/10/22 11:22:29]

Yes. But also, what happens if we're in an increasing state without REMB
negotiated and we stop receiving RR? I see the point when having REMB as a cap
and that is the normal state for us, but I think it would be interesting to
quickly discuss what we think is the right behavior.

I'll admit though it was a while since I dug deep into this code...

[stefan-webrtc, 2015/10/22 11:28:06]

Yes, if we don't have REMB this isn't great. Overall, I think we need some
mechanism to handle the case where we don't receive feedback, for instance
0-2 seconds since feedback: continue as normal
2-4 seconds since feedback: no increase
4-10 seconds since feedback: ramp-down towards min bitrate

But let's discuss!

[pbos-webrtc, 2015/10/22 13:16:06]

Sure, I put a TODO for now.

     if (last_fraction_loss_ <= 5) {
       // Loss < 2%: Increase rate by 8% of the min bitrate in the last
       // kBweIncreaseIntervalMs.
@@ -207,12 +206,12 @@ void SendSideBandwidthEstimation::UpdateEstimate(int64_t now_ms) {
 
     } else if (last_fraction_loss_ <= 26) {
       // Loss between 2% - 10%: Do nothing.
-
     } else {
       // Loss > 10%: Limit the rate decreases to once a kBweDecreaseIntervalMs +
       // rtt.
-      if ((now_ms - time_last_decrease_ms_) >=
-          (kBweDecreaseIntervalMs + last_round_trip_time_ms_)) {
+      if (!has_decreased_since_last_fraction_loss_ &&

[mflodman, 2015/10/22 07:06:57]

You can use 'accumulate_expected_packets_' instead of a new bool.

[pbos-webrtc, 2015/10/22 13:16:05]

Nope, accumulate_expected_packets_ gets reset every time last_fraction_lost_
gets updated, and not after UpdateEstimate succeeds.

[mflodman, 2015/10/22 14:34:34]

I was unclear in this comment, but we can avoid the bool if we use
'accumulate_expected+packets_' where I suggested in my comment above and reset
it after the Update function.

[pbos-webrtc, 2015/10/22 14:59:45]

That sounds like it'd be a bit harder to understand though?

+          (now_ms - time_last_decrease_ms_) >=
+              (kBweDecreaseIntervalMs + last_round_trip_time_ms_)) {
         time_last_decrease_ms_ = now_ms;
 
         // Reduce rate:
@@ -221,6 +220,7 @@ void SendSideBandwidthEstimation::UpdateEstimate(int64_t now_ms) {
         bitrate_ = static_cast<uint32_t>(
             (bitrate_ * static_cast<double>(512 - last_fraction_loss_)) /
             512.0);
+        has_decreased_since_last_fraction_loss_ = true;
       }
     }
   }