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

Fine,

I think the advice to maintain redundancy level, but increase the interval
between transmissions of text in a congested situation is good.

1. We have 300 ms between transmissions as the default. ( that makes it
quite burst-safe and keeps total load from text at a low level. )

2. We also agreed to having one original and two redundant transmissions as
default.

T.140 requires the wait for transmission to be less than 500 ms. So, there
is a room to extend the interval between transmissions in congested
situations to 500 ms even without breaking the standard. The users will
experience a slightly more jerky but still acceptable text presentation.

We will introduce this reasoning in next revision of RFC2793bis to be
issued soon.

Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom@Omnitor.se
--------------------------------------------

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Thursday, April 08, 2004 10:48 AM
> To: Magnus Westerlund
> Cc: avt@ietf.org; Gunnar Hellstrom
> Subject: Re: [AVT] How is SDP a=fmtp used for RFC 2198?
>
>
> Hi,
>
> On 8 Apr 2004, at 09:25, Magnus Westerlund wrote:
> ...
> > Colin Perkins wrote:
> >> --> "Gunnar Hellstrom" <gunnar.hellstrom@omnitor.se> 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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt