[R-C] REMB message, SSRC list and DiffServ

Randell Jesup randell-ietf at jesup.org
Wed Nov 2 17:14:11 CET 2011


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 at alvestrand.no <mailto:harald at 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 at alvestrand.no <mailto:Rtp-congestion at alvestrand.no>
>>     http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>>
>>
>
>
>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion


-- 
Randell Jesup
randell-ietf at jesup.org



More information about the Rtp-congestion mailing list