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

"Arnoud van Wijk" <a.vwijk@viataal.nl> Thu, 15 April 2004 12:50 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20428 for <avt-archive@odin.ietf.org>; Thu, 15 Apr 2004 08:50:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE67e-000065-2e for avt-archive@odin.ietf.org; Thu, 15 Apr 2004 08:37:38 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FCbcKl000360 for avt-archive@odin.ietf.org; Thu, 15 Apr 2004 08:37:38 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE5up-000447-LA; Thu, 15 Apr 2004 08:24:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE5Dt-0000gk-P6 for avt@optimus.ietf.org; Thu, 15 Apr 2004 07:40:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18037 for <avt@ietf.org>; Thu, 15 Apr 2004 07:40:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE5Ds-0000N6-00 for avt@ietf.org; Thu, 15 Apr 2004 07:40:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE5Cv-0000Iq-00 for avt@ietf.org; Thu, 15 Apr 2004 07:39:01 -0400
Received: from smtp.eweka.nl ([81.171.101.3]) by ietf-mx with esmtp (Exim 4.12) id 1BE5Bx-0000FB-00 for avt@ietf.org; Thu, 15 Apr 2004 07:38:01 -0400
Received: from solstice (ew-dsl-81-171-8-127.eweka.nl [81.171.8.127]) by smtp.eweka.nl (8.12.9/8.12.9) with ESMTP id i3FC0sWB080524; Thu, 15 Apr 2004 12:00:57 GMT (envelope-from a.vwijk@viataal.nl)
Message-Id: <200404151200.i3FC0sWB080524@smtp.eweka.nl>
From: Arnoud van Wijk <a.vwijk@viataal.nl>
To: 'Colin Perkins' <csp@csperkins.org>
Cc: 'Gunnar Hellström' <gunnar.hellstrom@omnitor.se>, toip@snowshore.com, avt@ietf.org
Subject: RE: [avt] Use of redundancy in rfc2793bis text transmission - optimizing interoperability
Date: Thu, 15 Apr 2004 13:38:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <44C7EB7C-8ECF-11D8-9065-000A957FC5F2@csperkins.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcQi3FP2OfsH1TQjQjaUJkFKp5hCDAAAHEUA
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

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: +31651921948
International text telephone: +31735588408


-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org] 
Sent: donderdag 15 april 2004 13:23
To: Arnoud van Wijk
Cc: 'Gunnar Hellström'; toip@snowshore.com; avt@ietf.org
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




_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt