RE: [avt] Use of redundancy in rfc2793bis text transmission - optimizing interoperability

["Gunnar Hellstrom" <[e-mail]>]

When I once selected RFC2198 to be the default mechanism, I calculated the
overhead, compared to FEC, and found that RFC2198 gave the lowest expected
total load.

For interoperability reasons it is very important to raise one method to
the default that everybody implements for general applications.

We are talking about a maximum of 2.5 kilobit/second including packet
overhead with a really energetic typer. That is lower than any usable voice
coder.

Gunnar
-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
[phone]
Mob: [phone]
www.omnitor.se
[e-mail]
--------------------------------------------


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Arnoud van Wijk
> Sent: Thursday, April 15, 2004 1:38 PM
> To: 'Colin Perkins'
> Cc: 'Gunnar Hellström'; [e-mail]; [e-mail]
> Subject: RE: [avt] Use of redundancy in rfc2793bis text transmission -
> optimizing interoperability
>
>
> Hi Colin,
> I agree. Now seeing Gunnar's addition:
>
> ********************************
> 4. Protection against loss of data
>
> For reduction of data loss in case of packet loss, redundant
> data SHOULD be
> included in the packets following the procedures in RFC 2198 [3].  If the
> application and the end to end network conditions are not known
> to require
> other methods or parameters, this method MUST be used, transmitting the
> original text and two redundant generations.
>
> As an alternative (or in addition) to redundancy, Forward Error
> Correction
> mechanisms MAY be used when transmitting text, as per RFC 2733 [8] or any
> other mechanism with the purpose of increasing the reliability of text
> transmission.
>
> There are also other mechanisms for increasing robustness of transmission
> that MAY be applied."
> *********************************
>
> The only thing I can say now is that we have to look at which
> mechanism is
> appropriate to use. With interactive text only on low bandwidth
> devices/networks. We can then use Forward error correction or similar
> mechanism then.
>
> If it is on high bandwidth devices and networks. The I think the
> redundancy
> method is best.
> I have had many interactive text conversations the last few
> weeks. Sometimes
> I noticed dropped characters due packetloss. And the video was a
> bit blocky.
> In that situation, the full redundancy of interactive text is the best
> solution. Throttling the Interactive text stream would not improve the
> connection and reliablility of text then. (this was using a total
> conversation client by the way).
>
> What do you think? Should this be added to the draft to get a better
> understanding which text transmission robustness is preferred?
>
> Greetz
>
> Arnoud
>
>
> Drs. Arnoud A. T. van Wijk
> Viataal
> Research & Development
> Afdeling RDS
> Theerestraat 42
> 5271 GD Sint-Michielsgestel
> The Netherlands.
> Mobile: [phone]
> International text telephone: [phone]
>
>
> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: donderdag 15 april 2004 13:23
> To: Arnoud van Wijk
> Cc: 'Gunnar Hellström'; [e-mail]; [e-mail]
> Subject: Re: [avt] Use of redundancy in rfc2793bis text transmission -
> optimizing interoperability
>
> Arnoud,
>
> On 15 Apr 2004, at 11:30, Arnoud van Wijk wrote:
> > Hmm.
> > When looking at an Interactive text stream, even with full redundancy,
> > the
> > used bandwidth is a fraction of the bandwidth used by video and audio.
> >
> > So knowing this, it is then desirable to cope with the packetloss by
> > using
> > the full redundancy. The effect of reducing the sending rate is nihil
> > when
> > combined with audio and/or video.
> >
> > Also, the minimal sending speed is equal to the typing speed, it is
> > real-time text after all on a character by character basis.
>
> The drafts states that text may be generated by automated systems at
> high rate in some scenarios.
>
> > With full redundancy on, you ensure that interactive text arrived
> > complete,
> > while the audio and video may stutter. I would not mind to switch off
> > the
> > audio then and continue with the video and interactive text.
>
> Consider the cases where there is no parallel audio/visual session;
> where the link capacity is low and is shared between real-time text and
> TCP traffic; or where there are large numbers of real-time text
> sessions.
>
> RFC 3551 says:
>
>        If best-effort service is being used, RTP receivers SHOULD monitor
>        packet loss to ensure that the packet loss rate is within
>        acceptable parameters.  Packet loss is considered acceptable if a
>        TCP flow across the same network path and experiencing the same
>        network conditions would achieve an average throughput, measured
>        on a reasonable timescale, that is not less than the RTP flow is
>        achieving.  This condition can be satisfied by implementing
>        congestion control mechanisms to adapt the transmission rate (or
>        the number of layers subscribed for a layered multicast session),
>        or by arranging for a receiver to leave the session if the loss
>        rate is unacceptably high.
>
> RFC 2198 says:
>
>     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.
>
> The text conversation draft does not implement congestion control, nor
> does it mandate that receivers leave the session when the loss rate
> becomes unacceptably high. Instead, it mandates the addition of large
> amounts of redundancy to hide the packet loss, and recommends that the
> session continue.
>
> Behaviour that directly contradicts the other RFCs may be appropriate,
> but this draft has to justify why it is acceptable, and why the
> recommendations in the other RFCs cannot be followed.
>
> Colin
>
>
>
>
> -
> This list is maintained by Snowshore Networks - http://www.snowshore.com
> All comments on this list are the comments of the message originators and
> Snowshore is not to be held responsible for any actions or comments found
> on this list. The archives for this list can be found at
> http://flyingfox.snowshore.com/toip_archive/maillist.html
>
>



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