Re: [rtcweb] Security issue: consent refresh

[Randell Jesup <[e-mail]>]

On 11/1/2011 10:34 AM, Magnus Westerlund wrote:
> However, we still have a pretty big issue to figure out when it comes to
> legacy devices and that is congestion/rate control. We are going to need
> it, and I really wonder if we can make exceptions to this at all. And if
> the legacy device don't implement even basic RTCP then this is a real
> issue.
>
> We added some text in the new version of WebRTC's usage of RTP document.
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
>
> 8.3.  Legacy Interop Limitations
>
>     Congestion control interoperability with most type of legacy devices,
>     even using an translator could be difficult.  There are numerous
>     reasons for this:
>
>     No RTCP Support:  There exist legacy implementations that does not
>        even implement RTCP at all.  Thus no feedback at all is provided.

Typically these devices aren't using codecs that can be throttled, so 
lack of congestion control doesn't really matter here.  (G.711, G.729, 
etc).  In theory you could switch codecs to a 
supported-but-lower-bandwidth codec, of course, but there would be no 
way to tell them to switch.  Effectively you're talking to a non-CC 
device; it will work or it won't.  I've never seen a 2-way video 
endpoint that didn't support RTCP in some way (though some are broken in 
odd ways) - they might exist, but I haven't seen one.

>     RTP/AVP Minimal RTCP Interval of 5s:  RTP [RFC3550] under the RTP/AVP
>        profile specifies a recommended minimal fixed interval of 5
>        seconds.  Sending RTCP report blocks as seldom as 5 seconds makes
>        it very difficult for a sender to use these reports and react to
>        any congestion event.

Congestion control based on AVP RTCP reports is possible, but with a 
very slow convergence time and unclear fairness results.  It does "work" 
in practice if not over-stressed.  I used such algorithms in the past 
for interop with "standard" videophones and endpoints (while operating 
my device in AVPF mode).  Such algorithms are likely significantly 
unfair in practice, though they may be fair "on average".  Congestion 
control here is more useful as a way to provide adaptation to link 
bandwidth for a single application than to provide sharing of a link.

>     RTP/AVP Scaled Minimal Interval:  If a legacy device uses the scaled
>        minimal RTCP compound interval, the "RECOMMENDED value for the
>        reduced minimum in seconds is 360 divided by the session bandwidth
>        in kilobits/second" ([RFC3550], section 6.2).  The minimal
>        interval drops below a second, still several times the RTT in
>        almost all paths in the Internet, when the session bandwidht
>        becomes 360 kbps.  A session bandwidth of 1 Mbps still has a
>        minimal interval of 360 ms.  Thus, with the exception for rather
>        high bandwidth sessions, getting frequent enough RTCP Report
>        Blocks to report on the order of the RTT is very difficult as long
>        as the legacy device uses the RTP/AVP profile.

This is in most cases much better than AVP timings, though not good. 
"Typical" usages might yield 300-1500ms RTCP intervals (much better than 
5000ms avg.)

>     RTP/AVPF Supporting Legacy Device:  If a legacy device supports RTP/
>        AVPF, then that enables negotation of important parameters for
>        frequent reporting, such as the "trr-int" parameter, and the
>        possibility that the end-point supports some useful feedback
>        format for congestion control purpose such as TMMBR [RFC5104].

Even without TMMBR, a RR-based CC algorithm with a fairly fast reporting 
interval should be able to provide some level of fairness and quick 
response (though far worse delay control).

>     It has been suggested on the RTCWEB mailing list that if
>     interoperating with really limited legacy devices an WebRTC end-point
>     may not send more than 64 kbps of media streams, to avoid it causing
>     massive congestion on most paths in the Internet when communicating
>     with a legacy node not providing sufficient feedback for effective
>     congestion control.  This warrants further discussion as there is
>     clearly a number of link layers that don't even provide that amount
>     of bit-rate consistently, and that assumes no competing traffic.
>
> We need to discuss if there is a reasonable way to resolve this or if
> this puts as strict or even stricter requirements then to support ICE.



-- 
Randell Jesup
[e-mail]