rmcat itermin Adaptive FEC for Congestion Control (Varun) ---------- Randell: Correct me if I'm wrong: adaptive FEC is only a significant win if the bottleneck queue is short, or AQM/fqcodel/etc is in play (and maybe with some cases RED). I didn't see any discussion of this in the paper. Varun: Loss is used for probing as congestion indication. Lars: One could use loss or delay as congestion indication. randell: Better probe without loss. lars: FEC does get you a lot for delay-based but it is still an indicator. randell: Please discuss this in the paper and how to use it dynamically. varun: It's also useful to protect against burst losses and can probe at the same time. Xiaoqing: Don't see burst loss at the transport; celluar network conceal this zahed: ?? slides 14 mirja: What's the traffic model? varun: we are using different youtube codings mirja: Are u app-limited? varun: Yes. Xiaoqing: ?? varun: we also have results with testbed not only simulation. michael: Different RTT? varun: In the slides. slide 17 lars: Also plot the media rate. Xiaoqing: Because here you can really see what you could have reached. varun: Black line is sending rate without FEC. mirja: Previous slide media rate was limited by congestion control? varun: Should also plot congestion control rate. slide 18 zahed: Delay is the delay as seen at the media? varun: Yes. slide 20 randell: Delay is influence by how congestion control reacts to congestion. varun: Different congestion controllers react differently. randell: How would congestion control react just to increase and decrease FEC? varun: In paper we have FEC recovery efficiency and correctness. randell: There is likely little or no FEC delay beside what the congestion control does; would be interesting to see results on audio quality and errors in the video. varun: Percent of recovery in time already say this. randell: Packets does not give you the whole story because different data might have different effects. varun: Need to incorporate in different proposals. geert: Bandwidth might drop strongly. In this case FEC doesn't protect. varun: Yes, but if you already have FEC, you can do this FEC adaptively by the congestion control. geert: You can't protect against strong changes. lars: This is to protect against overshoot when increasing. randell: With a small drop in capacity it still might help you some but probing might also hurt quality and this improves this part eventough you might not need all the FEC. slide 21 michael: Is this where capacity is constant; I meant where conditions change. varun: Send me what you exactly mean. xiaqing: This is a question for eval criteria. randell: Delay against depends mainly on cc reaction. zahed: Did you test different RTT? varun: yes, 50, 100, and 200. harald: How do you measure PSNR when you have lost packets? varun: Just copy previous one/freeze the video; depends on the video you use. randell: PSNR is not a great way to measure video quality. xiaqing: Not sure if experiment is right here; you would never see zero; what matter is range between 30-40 and you see big drops; increase vers. decrease should be reflected. Before we drop this metric we should figure out why this does not show up. varun: Have to check how we have calculated this. michael: Is symmetric as in both curves you see better PSNR if bandwidth increases. geert: Freezes happen often. michael: Is also depends on coding. varun: Not sure if this is freezing or quality dips. xiaqing: Experience might de dominated by freezes. harald: What was the I frame rate? varun: i p p p i; one every second. randell: We are getting to deep in video evaluation; PSNR is not good; most interactive video do not tend to have a lot i frames. karen: Do you need general framework? varun: Only on interactive between FEC and cc. michael: There are lost of different coding models and tricks. It's not clear if the joint optimitization is of interested here. colin: How particular are these results to the used coding? varun: Design approach could also be used by other schemes. varun: Someone wants to evaluate against its scheme? colin: Would this need to be stand-alone? varun: I would prefer to have this as part of a certain cc. randell: I'm (only) interested in this part if this helps us with issues that other proposals might have with AQM where probing results in large delays. xiaqing: This is yet another layer of adaptation so it depends on other schemes if they actually have issues. Update on NADA and testbed-based Evaluation Results --------------- ingemar: I'll read the paper; if you take wirless access it causes delay spikes eventhough you don't have competing traffic. Is this a serious problem? xiaqing: There is a background paper on TCP loss and delay co-existence. Took this idea and map it to delay-based systems. Delay spikes is a implementation issue because it depends on filtering. Risk might still exist and we are not 100% sure yet; we are still experimenting but filtering can help you in some scenarios. randell: Simliar to cx-tcp? xiaqing: Not familiar with all details but there are may techniques for this. david: The delay co-existence paper uses a probabilistic back-off technique. I'm not sure how well this translates to your equations. At high delays a small non-zero probability provides "back-pressure" to bring the system back into a low delay mode. slide 11 ingemar: Do you have jitter? Would be intersting. xiaqing: No. ingemar: Is this network or video frame deplay? xiaqing: It's ip packet delay; one way delay. randell: Rates goes than below actual link rate. Do you understand why it takes so long to get up again? xiaqing: Don't know but because of the feedback delay that goes to about the max limit as queue is almost full randell: This question is based on the paper: you are assuming a long time for the encoder to react of about 0.5s. That is incredible long time. xiaqing: Encoder is not in picture but there would be an additional buffer. varun: 10 reports in this adaptation period? xiaqing: Feedback gets also delayed because packet has stayed in the queue; it takes at least 0.5s to get report. zahed: And media source is ideal? zahed: Yes. zahed: Jitter makes quite a lot of difference. varun: Please also plot whole RTT as seen by media as I did. xiaqing: Maybe also reduce rate if absence of report as indicator for congestion...? randell: That's another indicator especially RTP where frames might be segmented, you could even report earlier. zahed: It this inter-packet or inter-frame arrival? xiaqing: ip-packet in additional header. randell: Or try to react more dramatically because 1-2s is a long time. ingemar: Why do you get additional variation? michael: ?? mirja: Do you use RTT here? xiaqing: No, only initially. zahed: ?? xiaqing: Feedback channel is also operating with time-variant feedback to make sure that it will not break. lars: Why is start up different for third flow? xiaqing: Because it already sees a queue. lare: So old flows have to release capacity? xiaqing: And there is not much incentive for them to do so. david: If you have a standing queue than all subseqent flows will see that as minumum and build up an additional queue. lars: It's the same for ledabt; long running flow might see minimum by chance. david: The algorithm could introduce this (randomness). lars: Oszillation rate makes me worrying. micheal: Part of it it's feedback dynamics; depends on parameters you choose. lars: But it quickly degrades if you leave the defined region. varun: Because you then have a different path propagation delay. xiaqing: This is no drastic change as it varies between 5 and 35 ms and rates are fairly stable. lars: It's interesting to see what happens if defined range is left. xiaqing: 100ms OWD doesn't give you good QoE anyway for media. zahed: Are you still using ?Mbit/s and start all flows at same time? lars: It's using different RTTs and so some are faster. xiaqing: Flows start about 0.1s apart from each other. varun: If you have fast feedback, that's where you ramp-up faster? lars: RTT-unfairness during start-up but while long-running not. michael: Other flows saw already the standing queue. zahed: It's at start up. xiaqing: All flows have 100ms feedback rate. varun: I though it scales with RTT; but than it's strange. xiaqing: But gamma is different. varun: Is this an artifact of the 500ms parameter? xiaqing: No. xiaqing: All flows operator similarly in convergence phase but at beginning of the probing the algorithm is more aggressive for smaller RTT flows. varun: That's the gamma? xiaqing: we could alos try and reverse order of entering the network. slides 21 varun: Would it be different for longer run time? xiaqing: Only calculated in steady state. slides: zahed: Are you reacting to packet loss here? xiaqing: Yes, that's the main signal. slides 26 lars: What happens in the start-up phase? Does it start at the old rate or use the same start-up behavior than initially? xiaqing: Uses start-up. randell: That's not what we see. xiaqing: Are people more interested in using old rate instead? zahed: Depends on algorithm. randell: Maybe halve of old rate. varun: I see some lower dots as well. xiaqing: That depends on the sample calculation rate. slide 27 zahed: How would you get OWD? xiaqing: Use RTP timestamp. zahed: RTP or separate? xiaqing: RTP zahed: Are these artifacts that have quite big spikes where you don't know if it comes from network? varun: Does this have a pacing buffer? xiaqing: This one doesn't; fairly jittery implementation. slides 29 mirja: Which traffic model do you use? xiaqing: A synthetic/greedy model; just because we have implementation issues still with video codec. mirja: So you say this is not ready for adpotion? xiaqing: I would like to ask others. Are there still any wholes in the algo? zahed: Would ask for real-time implemention with real-time video. Scream got a lot of changes when we tried this, w.g. app-limited, burtiness. We have not evaluted nada for wirless scenarios. varun: Constants are my mayor concern; might not be useful for everyone; they should be further discussed; and should be further analysed. randell: It's a good step forward from previous version and more tested now; mayor concern is that it needs to speed-up the reaction to drops, 1-2s is large; I realize that there are unavoiable delays but they should be further regarded. xiaqing: Should we also look at test case for more gradual step down. randell: Actually no, because real word does not work this way. Most drops will be abrupt. michael: Varun, point taken that's why we have an absolute maxmium of delay. We still plan further work to work on reverse path but so far we spend a lot of time on test cases. randell: If you say it is only optimized for this range, it does mean that you cannot switch to a different set of parameters for dfferent scenarios xiaqing: But know where to use which set is important for evaluation. Update on Scream and evaluation results -------- slide 6 geert: Scream enforces frame skipping at the encoder. zahed: Yes, this is coming from wireless test cases because its better than overload the network when capacity is decreasing. geert: Rate control might support this and some might not. zahed: That's what we want to happen but might depend how it's implemented; e.g either don't send frame to endoder or you are able to set a flag to skip a frame. Not every encoder might have this option. xiaqing: It is fair to see frame skipping as something that should be outside the cc. zahed: Sure others should consider this, but for scream this is part of the cc to not have to react to all spikes and therefore to have some slag; we need to have this backup mechanism as soon as we note that this is congestion. randell: Let the encoder decided if the right thing is reduce quality or skip a frame. The decoder might need further information. So it just depends on the API. zahed: ?? randell: When telling to encoder to drop, a frame you modified the encoder and this should be more generalized to be used with different schemes. michael: Last graph is the cwnd that the algo thinks it could send? zahed: Yes, same as in tcp. michael: We should have a new mechanism to say this is the amount you could have or cut back. m. welzl: Is this sensitive because of low feedback rate? zahed: Might need to ack the acks. m. welzl: That is a general issue. ingemar: Originally I had it, but could make some sense. m. welzl: If you send ACK all the time and that's different than this. karen: Or you could probe for an ack if your haven't received feedback for a certain time. zahed: Use an ack factor of 32. If some get lost, we get a notification and we therefore are not stucked only if RTP feedback gets lost we don't have any feedback. michael: If you lose feedback, you have to be careful and you don't care if problem was on forward or backward case. But that is not necessary true for all situation. Should evaluate case where feedback path has jitter or loss. This is not against scream; scream is very conservative but in some scenarios we wouldn't want to have this. I would like to talk about what to do in cases of lack of feedback. zahed: Don't want to stop sending if 1-2 reports gets lost. We have this ack vector. xiaqing: Loss of ack should not have a big effect; would hurt to send everything 2-3 times. ingemar: loss of feedback is just a short glish in sending rate and wouldn't change the delay much. It's not dramatic. slides 11 mirja: Why is there more throughput with frame blanking? zahed: Because of more drops of TCP. mirja: Without frame blanking you have basically zero throughput. zahed: Yes. slides 23 xiaqing: Why didn't you prensent results on basic test cases? zahed: No, this is update to previous on wireless. ingemar: This is also to show how to model non-ideal video traffic. xiaqing: Non-ideal could also be based on trace. What dou you think; this is good enough to capture real effects? xiaqing: We should maybe aims for gradual degradation of ideal case. zahed: This might not get as much as you want. mirja: Is this a framework or a stand-alone candidate? zahed: Candidate with ledbat as a fixed part. mirja: Is this ready for adaption? zahed: We could adapt it now and still split up later. xiaqing: There are many elements which needs further understanding. zahed: Depends if other actually whats to use this. xiaqing: Depends on ledbat. zahed: It's not ledbat anymore. We added stuff on top but still could take out letbat xiaqing: Would still be clearer to separate out pieces that everybody could use. varun: It's written as complete proposal. If we want to break up we should decide before adaption. Not opposed to have this as a framework. Because there are things that others can use but depends if other want to use it. zahed: These additions are made to make ledbat work for video. ingemar: Network control and rate control might be ortogonal because of bitrate-limited sources and you have interdependance which make it tricky to have this separated. zahed: We need to combine them. michael: I disagree with this statement. We have to optimize it as a common problem but as long as you get the right signal you can make the right decision in the encoder. You put constraints on the decoder and they don't like these constraints. zahed: The encoder does never optimize for the network but always for video quality and in the network you have to also take e.g fair share in account. michael: ?? m. welzl: I agree and on splitting: the upper layer gives you buffer information and can be full or can change state. That's what you can get. For evaluation you use a certain coding but that should not be important for you algorithm. zahed: Framework should be separated. Than the actually congestion control system should not do frame skipping but encoder might decide to change rate. m. welzl: cc calculates rate and should give feedback on this. Splitting up would give you pieces that might go into other drafts. zahed: if you have this as a framework you have to correlated this with other drafts. xiaqing: we already have the app-interaction draft but don't need an own framework draft. zahed: app-interaction doesn't give a framework. m. welzl: But maybe it should andnot only say how it could be done. varun: app-interaction could really do this. Right now we don't have concrete mechanisms but as soon as we have them this could be changed. zahed: I agree if we know which algorithms belong to rmcat karen: We could do that. Right now you should split your doc and write-up what could be deleted if we have another solid document on app-interaction. varun: When presented this first, there were all these interfaces. zahed: I have a suggestion: in next version we split up the text within one document and then we can decide if we want to make a framework out of it or if we put in the app-interaction varun: What happen if you remove these parts and your cc doesnt take this into account? zahed: Video encoders don't have these functionality yet. That's why we try in scream to assume that we dont have it. If you dont do frame skipping it hurst a lot. So it's in the main part of scream. m. welzl: But it's not cc functionality. xiaqing: We should talk to encoder people; it's more a wish list. It's outside the scope of rmact. ingemar: What happens if scream works without frame skipping? You get much higher frame delay but ip pacekt delay does not increase that much. randall: Direct frame skipping by transport has issues but having this interface to give information to the encoder is important; what the possible rate is. zahed: Yes, codec guys have to decided what to do. Michael: Congestion control should provide info on the buffers the codecs needs to react accodingly. Colin: Control of codecs is usually handled at the application layer. Zahed: The API should be from CC to application layer as in the API interactions draft. Geert: It's very complicated to standardize codec APIs. Randell: That's why this must be an API in between CC/transport and the application and the application will ty to respond best possibly depending on the application logic and codec Mirja: How useful is it if RMCAT defines application API if the application does not support the API...? Michael R: This a joint optimization problem, but it can be solved. Such apis can be defined. It is useful to standardize the interface in this group, when applications learn that there is this info that transport/CC can provide, they will use the info and react. Varun: Codec should itself calculate the undershoot. What if the codex does not honor? michael: If codex gives you a packet you have told it not to give, you drop it and tell it. Then codex will know to react accordingly. Xiaqing: If the codec does not react accordingly, it is not the problem of the transport/CC but the problem of the codec.