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

["Arnoud van Wijk" <[e-mail]>]

Research has shown that most interactive text conversations use about 120
characters per minute.

Perhaos we can add that also to the draft to give people a better
understanding what the most likely speed will be in most cases.

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Gunnar Hellstrom
Sent: vrijdag 16 april 2004 10:51
To: Colin Perkins
Cc: [e-mail]; [e-mail]
Subject: RE: [avt] Use of redundancy in rfc2793bis text transmission -
optimizing interoperability

Colin,

The case with a user pasting in large amounts of text into a conversational
system is not occurring in reality. If you cut and paste something, it is a
short piece, like an address or so. Users haver much more efficient means
to transmit documents, so text conversation is not used for that
application. It was technician?s thought that made the wording come into
rfc2793bis.


I suggest changing that section in chapter 1 to the following:


"The text is supposed to be entered by human users from a keyboard,
handwriting recognition, voice recognition or any other input method.  The
rate of character entry is usually at a level of a few characters per
second or less. In general, only one or a few new characters are expected
to be transmitted with each packet. Small blocks of text may be prepared by
the user and pasted into the user interface for transmission during the
conversation, occasionally causing some packets to carry more payload."

With that, I interpret that the discussion has led to acceptable wording
for use of redundancy and congestion considerations, and I can submit a new
revision for publication.

Thanks,
Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 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 Colin
> Perkins
> Sent: Thursday, April 15, 2004 1:23 PM
> To: Arnoud van Wijk
> Cc: 'Gunnar Hellstrom'; [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
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
>
>


-
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