Re: [AVT] How is SDP a=fmtp used for RFC 2198?

[Colin Perkins <[e-mail]>]

Hi,

On 8 Apr 2004, at 09:25, Magnus Westerlund wrote:
...
> Colin Perkins wrote:
>> --> "Gunnar Hellstrom" <[e-mail]> writes:
>>> On number of redundant generations for text transmission.
>>> ---------------------------------------------------------
>>> There is a need for one original and three redundant copies as the
>>> RECOMMENDED default for text transmission. That will meet the service
>>> requirements of <1% character error rate in conditions when voice is
>>> barely usable ( from F.700 & F.703 ). That can be in a society crisis
>>> situation when the network gets congested, or in next outbreak of 
>>> worms
>>> crawling the Internet.
>>> Audio can be used for voice, and video for sign language down to 
>>> around
>>> 30% packet loss. It can be a good goal to maintain usable text
>>> transmission at that packet loss rate.
>>>
>>> Try the calculator in http://packetizer.com/iptel/toip/cercalc.html
>>> and find that you need 3 levels of redundancy to get under 1% 
>>> character
>>> error with 30% packet loss. The character error figure for text coded
>>> text is at the bottom of the page.
>>>
>>> It is not expensive. The RECOMMENDATION is to send text packets with 
>>> 300
>>> ms intervals, and only when there is something to transmit. The
>>> redundancy levels take little space compared to the packet and RTP
>>> header.
>> I'd expect the gain from sending 3 levels of redundancy to be minimal
>> compared to a single delayed redundant packet.
>
> Yes, the gain for each redundancy level, becomes less and less. And I 
> would think that a third level would only be needed when packet loss 
> rates are extreme. At 10% independent packet loss rates, it would 
> result in that a third level drops the after redundancy loss rate from 
> 0.1% to 0.01%. Also for T.140 the risk for burst loss becomes 
> significantly reduced due to the long inter packet delay when using 
> the recommended buffering. Also as it is a interactive protocol the 
> loss can be repaired on human level, by "say what?" or the actual text 
> redundancy.

Also, if packet loss is bursty, the advantage of sending additional 
levels of redundancy is reduced compared to delaying the redundancy 
longer than the expected burst duration. Depends on the statistics of 
the packet loss, but the measurements I have taken indicate that loss 
often occurs in short bursts, rather than uniformly.

> But it seems natural to monitor the packet loss, and if they become 
> excessive, a client may increase the level of redundancy, while at the 
> same time make efforts to reduce the total bit-rate sent (see below).

Agreed, with the proviso that you can often get the same effect as 
increasing the level of redundancy by changing the delay before the 
redundant data.

>>> 3 generations of redundant data may sound excessive, if you have a
>>> network where loss is usually under 1%. But, if there is a risk of 
>>> 30% in
>>> a crisis situation, you should follow the recommendation.
>> As noted in the security considerations section of RFC 2198:
>>    Whilst the addition of low-bandwidth redundancy to an audio stream 
>> is
>>    an effective means by which that stream may be protected against
>>    packet loss, application designers should be aware that the 
>> addition
>>    of large amounts of redundancy will increase network congestion, 
>> and
>>    hence packet loss, leading to a worsening of the problem which the
>>    use of redundancy was intended to solve.  At its worst, this can 
>> lead
>>    to excessive network congestion and may constitute a denial of
>>    service attack.
>> I believe the same issue is applicable to text streams, and 
>> accordingly do
>> not agree that sending 3 levels of redundancy is appropriate.
>
> In regards to congestion control, I would think that the correct 
> response rather than reducing the level of redundancy is to increase 
> the buffering, resulting in fewer packets per second. As a T.140 
> payload even with three levels of redundancy is most likely smaller 
> than the headers, the most effective congestion reduction method is to 
> reduce the number of packets sent. I think that such a statement on 
> how to perform congestion control might be appropriate.

If it's possible to send fewer packets per second, that is certainly 
better.

Colin


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt