On 11/01/2011 02:12 PM, Justin Uberti wrote:
Good point. Keep in mind that even within a single source/SSRC, packets may be sent with different DiffServ markings (consider speech vs silent audio, or different temporal layers for video) I get a headache just thinking about how to signal congestion control for that .... especially since it's not improbable that the Diffserv bits will be cleared by the time the packets get to the recipient, so it might be impossible for the recipient to tell which packets experienced what queues.
Can we add a warning to our documents saying "don't do this if you use this type of congestion control", or do you think the practice is widespread enough that we have to deal with it? (if nobody's doing it, a warning might be enough to prevent anyone from starting it.)
On Tue, Nov 1, 2011 at 4:39 PM, Harald Alvestrand <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
I just remembered one reason why we put an SSRC list in the REMB message, and I don't think we've mentioned this on the list....
If SSRCs get sent with different DiffServ codepoints, they are going to experience very different congestion states at intermediate routers. It doesn't make sense to give feedback on them jointly or on average.
We don't know yet how we should divide those SSRCs into different groups, but it's good to have the ability to do so without changing the signalling.
The congestion state on a set of SSRCs should only be applied as a basis for controlling traffic over the set of data that is sent with the same DiffServ markings. (Grammar bad. I beg forgiveness, and hope the meaning carries.)
Harald
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no <mailto:Rtp-congestion@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtp-congestion