REMB message, SSRC list and DiffServ
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
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) On Tue, Nov 1, 2011 at 4:39 PM, Harald Alvestrand <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 http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
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
On 11/2/2011 11:48 AM, Harald Alvestrand wrote:
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.
If there is going to be differential marking, we will need to be able to specify either in the ROAP messages and/or in RTCP messages what channels are related (and data channels would have to be specified in ROAP; RTCP would allow for more dynamic handling of media channels without re-OFFER/ANSWER). A form or variant of SDP grouping could be used. That answers the first part of the question: how do you signal grouping. Having the algorithm handle it is the second part. You might have to treat them as separate flows; however the least-privileged flow seeing delay might cause the sender to constrict a more-privileged flow, depending on the application priorities and how modifiable each flow is.
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.)
We either need to design for it (which I think is doable, though it would make evaluating it and testing it "interesting"), or recommend against it. The other thing to consider is that a transport service might impose such differentiation without our knowledge, such as a mobile carrier which provides more-timely-delivery to short (audio) packets relative to large (video) packets, perhaps even without any direct intention for it to be differential by media. I'm not sure that actually would occur in practice, just trying to anticipate possible issues.
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
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Randell Jesup randell-ietf@jesup.org
participants (3)
-
Harald Alvestrand -
Justin Uberti -
Randell Jesup