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

[Magnus Westerlund <[e-mail]>]

Hi Colin and Gunnar,

See comments inline

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. 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).

> 
>>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.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]


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