Hi, That was a very interesting answer, thanks! Comments in line:
On 14. okt. 2013, at 08:39, Toerless Eckert wrote: > > High level answer: I think it has not been done so far because it is not that > easy, and it requires both good thinking of how to do it from the video > encoding > expert and the network QoS experts. > > I think it would be great if video flows would give per-packet priority > indications. I think most of the reasons brought up so far in this thread are > no good > reasons not to do it: I agree! > - Even without B frames, different packets can have different prioties. I/LTR > frames vs. P frames for example. Equally in SVC. > - FEC is not free but costs quite a bit of overhead. And its not particularily > well protecting against burst loss happening during burst collisions when > new competing flows cause queue overrun. > - Playout buffers in receiver apps can be quite large. STBs supposedly have > 100 msec or more. So reordering of different priority packets should not > be an issue. Even with low-delay video, the reordering that could happen > in the network just means that some packets of the flow arrive earlier than > expected under the contention conditions. Besides, you can also have > different > drop priorities without packet reordering within the same queue. In fact > AF4x for example is defined to have that property (no packet reordering). > > IMHO, the issues why nothing has been done so far are rather: > > - There may not be enough well understood value analysis, eg: How well could > network with differentiated drop policies effectively protect higher > priority packets over lower priority packets. Yes, this is widely known at > the class level, but not necessarily for packet distributions of different > packets in the same flow. We've done some simulations on this that we > could show that IMHO looked pretty good. At least to some degree, this must be a function of the queue length, I think. The shorter your queue, the less likely it is that you see more than one packet from the same source... if important packet #1 from source X and unimportant packet #2 from source X are not in the same queue together, you probably can't reasonably protect #1 from the impact of #2. > - Why drop if you could do ECN plus rate-adaptive downspeeding. The answer is > IMHO a bit more complex. I agree. > In summary, i think priority dropping is good to > deal with short term burst collisions and i think they can become quite > likely > for RMCAT. For dealing with ongoing congestion you obviously want > downspeeding, > and ongoing may be as short as maybe >= 2..10 seconds. If you do have > priority based drop support in the network, i think that could fare better > than ECN because it does resolve the burst collision as good as possibe > in addition to a congestion notification. PCN of course would be best to > have, > in which case the window of applicability for priority dropping shrinks to > less likely burst collisions. > > - How do you maximize the value of priority dropping in the video codec. > Ideally you build your codec to have real discardable frames that are not > predictor for other frames. But that as PSNR impacts. So this gets into > the secret sauce of codecs. There, I think the answer can easily be found in multimedia literature. There are many papers out there that evaluate such effects, e.g.: Michael Schier, Michael Welzl: "Selective Packet Discard in Mobile Video Delivery based on Macroblock-Level Distortion Estimation", IEEE Infocom MoVID 2009 workshop, 24 April 2009, Rio De Janeiro, Brazil. as only one example. > - How do you signal packet priority. DSCP is really ugly (TM). Besides, its > really ugly to set from application (TM). An RTP header extension field > would be IMHO much nicer. I agree that DSCP is ugly; I was thinking that one would have to even reserve bits in DSCP because, despite different priorities *within* a connection, one might still apply e.g. DiffServ to differentiate between 5-tuples. Indeed, given that this is functionality that's only meant for devices that identify 5-tuples, something above IP would make sense. So I think I agree that an RTP header extension would be a good choice. > - How do you motivate codecs to indicate packet priorities if they have to > fear that video flows with some packets marked "low priority" would > ultimately see more packets dropped than flows without any "low priority" > indications. For that we've got draft-lai-tsvwg-normalizer-02.txt Well, but here we're talking about a marking that only means "relative priority, within the same connection". So there shouldn't be any risk in setting low priority, really. Cheers, Michael
