huitema
commented
1 year ago Here is a graph comparing the end-to-end delays for warp transmission with "delay based" congestion control versus group based:
This could be improved in at least four ways:
1) detect the congestion sooner, by tweaking some parameters. Did some trials, but there was no obvious improvement.
2) implement the "differential priorities" suggested in the WARP draft. This should be a separate PR.
3) implement some kind of "skip ahead" on the client side, to not try to play P frames of a previous group if the I frame of the next group is already received. In this particular sample, the effect would be to play the first I frame 140ms sooner, and possibly sooner than that if differential priorities are implemented. Again, should be a separate PR.
4) start pipelining data from unistreams as soon as it arrives, without waiting for the whole frames. Another separate PR.
As is, only verified for single stream and warp transmission modes. We need to verify it for datagrams before merging. In fact, we probably need to port a dozen more tests to be really sure.
The first impression is that it works, there are fewer packets dropped than with the "delay based" congestion that we are currently using, but the queuing delays are much longer. That's expected: if a transmission is slow, we will build up a queue until the beginning of the next group of blocks arrive. On the plus side, the algorithm is much more robust against improper setting of flags in the client, e.g., mistakenly marking P frames as "can be dropped", which causes loss of the whole block.