Potential bug in sprout code?

[Fu Jiantao]

Hi Alfalfa team,

Thank you very much for sharing this fantastic work, even though it's 10 years old, I still found value there in how you capture the network dynamics and reproduce in the lab environment, and the congestion control algorithm is totally different from traditional ones. In industry the cellular network performance for real-time media is still very challenging, that is why I'm getting back to look in more detail on how this works.

I've been playing around the code, the simulation code "multisend/infer/vbrssp.cc" works very well when I feeding into whatever pps file, no matter the fake 200.pps, 1000.pps or those collected from real-world cellular networks, it gives pretty good estimation.

Then I tried to evaluate the sproutbt2 with cellsim, I firstly verified the cellsim setup with iperf to make sure it works, then I started with the simplest one 200.pps, ideally it should reach around 2.3 mpbs, however sproutbt2 can only get around 500kbps ~700kbps, which is not expected, I then checked the implementation, and found the following code:

void SproutConnection::update_queue_estimate( void )

{

uint64_t now = timestamp();

/* investigate decrementing current forecast */

int new_forecast_tick = std::min( int((now - remote_forecast_time) / conn.get_tick_length()),

operative_forecast.counts_size() - 1 );

while ( current_forecast_tick < new_forecast_tick ) {

current_queue_bytes_estimate -= 1440 * operative_forecast.counts( current_forecast_tick );

if ( current_queue_bytes_estimate < 0 ) current_queue_bytes_estimate = 0;

current_forecast_tick++;

}

}

What makes me confusing is the while loop here, my understanding is that "operative_forecast.counts" gives the accumulated packet counts estimation since "remote_forecast_time", and the packet count drained estimation during "current_forecast_tick" and "new_forecast_tick" should be "operative_forecast.counts[new_forecast_tick] - operative_forecast.counts[current_forecast_tick]"?

I tried to fix this however that doesn't help, actually drain less than before. And then I found when it recv the forecast below:

string SproutConnection::recv( void )

{

ForecastPacket packet( conn.recv() );

if ( packet.has_forecast() ) {

operative_forecast = packet.forecast();

remote_forecast_time = timestamp(); // - conn.get_SRTT()/4;

current_queue_bytes_estimate = conn.get_next_seq() - operative_forecast.received_or_lost_count();

assert( current_queue_bytes_estimate >= 0 );

current_forecast_tick = 0;

update_queue_estimate();

}

return packet.data();

}

the RTT estimation is commented, I assume taking that into account would give a more accurate estimation because the prediction is given before RTT/2? This one helps on improving the throughput and it's around 1mbps on average, however, still have a gap there, raising the lower percentile 0.05 helps too, but I'm not sure whether any others I'm missing.

I know this is an old topic and you may have already moved interests to other areas, wish I could check this work earlier!

Thank you!

Jeromy