Subject: [rmcat] SCReAM Questions, comments and answers

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 4 Aug 2014 16:17:28 +0000

Hi
First of all, thanks for the comments to the SCReAM proposal during the RMCAT session. Below I add some more info based on Piers's comments as well as the comments that I see in the meeting minutes.

+ Intraprotocol fairness (Piers's comment)  : A method very similar multiplicative decrease is implemented in the SCReAM code that we use. In a few words it reduces CWND if the smoothed OWD exceeds half the target delay AND more than 10 RTTs have elapsed since the last CWND reduction. This works so-so but I needed to add another extra check that inhibits this function if the bitrate is low.

+ Media on hold or frame blanking (also related to Piers's comment): The idea is to avoid sending high bitrate media (video) for a short duration (~1 RTT) and measure the OWD during this time. To aviod poor video performance it is recommended to inhibit the video encoder during these periods as it makes it possible to maintain a correct codec state.
This serves two purposes:
1) Make possible for the flow (as well as other intraprotocol flows) to more correctly update their base delays, the rationale is that  the queue occupancy in the bottleneck should drop to zero and then all intraprotocol flows should get a  more correct base delay estimate. This solves the intraprotocol fairness issue quite well.
2) Detection of competing (TCP) flows and adjustment of delay target. If there is only one flow then the OWD will drop to zero during the media on hold period otherwise OWD will have a higher value, the delay target is then set equal to the measured OWD. This is complemented by function which periodically checks if the delay target can be decreased in the case that the competing flow is removed.

Comment to what is written in the preliminary minutes.

+ Frame blanking and bursts: I am not sure that I understand the comment. The idea is to inhibit the video encoder for a short duration, the duration is so short that the codec state and the congestion window is maintained as is, in other words, no slow start is taking place. Now, because the prediction gain is reduced, there is a possibility that the PSNR may drop temporarly after a frame blanking period because of reduced prediction gain, currently I don't know exactly what the effect of frame blanking is.
+ 32 bits ACK vector: This was a design choise in the simulator. Currently it is more than enough. It is however possible that RLE encoding over a larger span is needed if the bitrates are higher and/or min RTT is larger.
+ Bytes in flight or packets in flight : I would recommend bytes in flight, packets in flight can become messy as not all RTP packets use up the entire MTU, one example is if one IR frame is split into several RTP packets due to MTU restrictions.
+ Dropping RTP packets : This should be avoided and used only as a last resort to remove RTP packets that are anyway too old to be rendered. It is instead better to avoid encoding new RTP packets (frame skipping) as long as the sender queue is too larger, this helps to keep the video codec state in a healthy condition. There may be other methods than frame skipping as Mo mention, the main point is that it should be possible to reduce the temporal sender queue size growth in cases where the link thoughput drops.
+ Prediction in order to reduce jitter: I have tried out a method where the video bitrate increase is slowed down around the last known congestion (inflection) point. This is very similar to how TCP BIC or Cubic behaves, the method increases the elapsed time between delay spikes but does not reduce the size that much. In addition I implemented a 1st order prediction on the OWD samples and use that as a trend indicator. This manages to remove almost all jitter spikes and for some unknown reason it improves the intra protocol fairness greatly. There is more experimentation needed to make sure that it does work well with the LTE test cases.

Probably missed a few comments/questions, please feel free to ask.

Will add more details around the above in the next update of the draft.

/Ingemar

=================================
Ingemar Johansson  M.Sc.
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com

"The difference between stupidity and
genius is that genius has its limits."
Albert Einstein
=================================