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

From: Gunnar Hellström <[email-masked]>
Date: Wed, 14 Apr 2004 22:59:04 +0200

I often get comments on the real time interactive text conversation transport
RFC2793bis, that it must more clearly require the use of redundancy to assure
good success rate in text transmission even in bad network conditions.

Next version of draft-ietf-avt-rfc2793bis is about to be published, and I would
like to have  agreeable wording on this issue.

A traditional requirement for basic text conversation quality is that no more
than 1% characters may be lost in conditions where voice communications is
barely usable. Where characters are dropped marks for missing text should be
inserted in the received text. A higher quality level, called good text quality
requires no more than 0.2% characters to be dropped. This is of course no exact
scientific measure and many factors influence both the loss and the perception
of usability of voice conversation, but it gives a fair design goal.

With voice coding and transmission schemes prevailing today, voice gets barely
usable around 20% packet loss.

Therefore, in order to assure proper interoperability with the required quality
level for text at 20% packet loss, we need to require one original and two
redundant transmissions according to RFC2198. ( lowering text loss to 0.8% )
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Thu, 15 Apr 2004 10:55:10 +0100

On 14 Apr 2004, at 21:59, Gunnar Hellström wrote:
> Next version of draft-ietf-avt-rfc2793bis is about to be published, 
> and I would like to have  agreeable wording on this issue.
>
> inserted in the received text. A higher quality level, called good 
> text quality requires no more than 0.2% characters to be dropped. This 
> is of course no exact scientific measure and many factors influence 
> both the loss and the perception of usability of voice conversation, 
> but it gives a fair design goal.
>
> Therefore, in order to assure proper interoperability with the 
> required quality level for text at 20% packet loss, we need to require 
> one original and two redundant transmissions according to RFC2198. 
> (lowering text loss to 0.8%)

Why do you think it acceptable to be sending at full rate when there is 
20% packet loss, rather than reducing the sending rate to reduce packet 
loss? Do you have some analysis to show that, with typical text 
conversation packet rates and network RTTs, transmission with 20% 
packet loss is TCP friendly (or otherwise)?

The requirements you list may be appropriate from a media quality 
viewpoint, however you also need to demonstrate that the payload format 
is safe to deploy. This is particularly important for a format which 
adds a large amount of FEC to allow it to operate in the presence of 
large amounts of congestion, but doesn't specify a congestion control 
response.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Thu, 15 Apr 2004 12:30:58 +0200

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.

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.

That is how I see it.

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: [email-masked] [mailto:[email-masked]] On Behalf Of Colin
Perkins
Sent: donderdag 15 april 2004 11:55
To: Gunnar Hellström
Cc: [email-masked]; [email-masked]
Subject: Re: [avt] Use of redundancy in rfc2793bis text transmission -
optimizing interoperability

-- 
Colin Perkins
http://csperkins.org/

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Thu, 15 Apr 2004 13:38:06 +0200

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

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: donderdag 15 april 2004 13:23
To: Arnoud van Wijk
Cc: 'Gunnar Hellström'; [email-masked]; [email-masked]
Subject: Re: [avt] Use of redundancy in rfc2793bis text transmission -

Arnoud,

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

> 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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 15 Apr 2004 14:06:39 +0200

Colin,

You say:
>loss?
Another section of the proposed new edition of RFC2793 takes up congestion
control:
---------------------------------------------------------------------------
--------------
8.4 Congestion Considerations

Even if the network load from users of text conversation usually is very
low, consideration should be paid to the contribution to network congestion
caused by this application. In circumstances where the text stream is
considered to contribute to a large degree to an experienced congestion
situation, it is RECOMMENDED to momentarily increase the shortest time
between transmissions described in section 5.1 from the recommended 300 ms
to 500 ms.
---------------------------------------------------------------------------
-------------
OK?

You say:
> Do you have some analysis to show that, with typical text

Does this mean that you want me to investigate if we should propose a TCP
based mechanism for text conversation?
The current standard ( RFC2793 ) make use of RTP. We have discussed using
TCP many times, and always ended up with the conclusion that RTP must be
the default. You may add on other mechanisms, but for interoperability
reasons we need to have one common default method.
Some reasons to stick with RTP as the default method are:

1.-Only RTP is standardised as a medium transport in the published versions
of SIP and SDP.
So, it is not currently possible to declare TCP in a properly standardised
SIP phone environemnt, and that is one of our main goals.
I know that TCP media in SIP is discussed and even used, but it is
definitely not mentioned in any RFC.

2.-TCP in not suitable in a loosely coupled conference situation. If you
want to send real time subtitles together with a speech in video and voice,
RTP is required.

3.-When NAT routers include mechanisms for taking SIP calls through
properly, we can be sure that RTP streams are handled well. Since TCP media
is not yet a standard in SIP, we cannot be sure that TCP streams will be
handled properly. We want future IP telephony to include video, text and
vocie streams without obstacles, and therefore we want the text to be
treated as the other media and not blocked by NAT-routers when voice and
video gets through.

4.-Same discussion as 3, but for Firewalls.

5.-If TCP is used, and you have a problem, the TCP session gets broken and
must be re-established . In that process, there is a risk of character
duplication, that needs to be avoided or marked. An RFC2793-like
transmission on top of TCP seem to be required to meet user requirements.

6.-The few extra bytes we introduce for two levels of redundancy may turn
out to cause less bits to transmit than TCP. Neither is close to any use of
audio or video in bit load on the network.

Conclusion: Standardise RTP, use it as the default, experiment if you want
with TCP and get it eventually standardised as a negotiable option if it
turns out to have benefits.

>large amounts of congestion, but doesn't specify a congestion control
We already took congestion considerations when we included the requirement
to buffer text to transmit in 300 ms intervals. That means at most three
packets a second, with quite small payload. And they are only transmitted
when the users have typed text. So, normally there will be long pauses with
no transmission. With the extra description that if we realize that we
contribute to congestion we should increase to 500 ms between
transmissions, I think we have a world record in low load from a streaming
medium.

Regards

Gunnar
-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

> Sent: Thursday, April 15, 2004 11:55 AM
> To: Gunnar Hellström

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 15 Apr 2004 14:16:46 +0200

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

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Arnoud van Wijk
> Sent: Thursday, April 15, 2004 1:38 PM
> To: 'Colin Perkins'
> Subject: RE: [avt] Use of redundancy in rfc2793bis text transmission -
> -
> 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
>
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 15 Apr 2004 12:23:07 +0100

Arnoud,

RFC 3551 says:

RFC 2198 says:

Colin

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 16 Apr 2004 10:51:25 +0200

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
Renathvagen 2

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Colin
> Perkins
> Sent: Thursday, April 15, 2004 1:23 PM
> To: Arnoud van Wijk
> Cc: 'Gunnar Hellstrom'; [email-masked]; [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Apr 2004 13:17:08 +0200

Hi Gunnar,

I think the congestion consideration section is a required feature. 
However I think the text needs improvement. First I think it should 
reference the relevant sections of RFC 3550, 3551, and 2198.

Secondly, I think that the recommendation part need to reworded. The use 
of "contribute to a large degree" is not acceptable. If the T140 stream 
is sending at a higher bit-rate than what TCP would achieve in a best 
effort network, it needs to take avoidance. The lowest transmission rate 
that a TCP stream sending full 1500 bytes packets can be backed off too, 
is one packet every 2 minutes. That represents a bit-rate of 100 bits 
per second. As one RTP packet without payload per second has higher 
bit-rate I still think there is need to have a consideration. However 
this boils down to that a text sender MUST perform congestion control on 
its stream in a best-effort network.

Third, I think one should give clear recommendations to what do to make 
it possible to reduce the bit-rate for text streams. To my understanding 
the reductions should be made in the following order:

1. Increase buffering up to limit 500 ms.
2. Reduce amount of redundancy until loss rate are at service limit
3. further increase buffering times beyond 500 ms.

I would not expect that one would need to do the third option unless the 
  congestion is extreme. However the text stream would need to reduce 
its rate further if it is unfair. Another reason for having this 
consideration is that I think a text user is much more persistent in 
their usage then what a voice call would be, due to the ease of adding 
redundancy.

However I do agree that one will have incredible loss rates to get TCP 
to back off to the level a typing user would result in. If one looks at 
RFC 3714, one could notice that a 4.75 kbps (audio user data) 20 packet 
per second stream, RTT=100 ms is not fair when it experience packet 
losses of 40%. But there are a few assumption here which may not totally 
hold in this scenario. However I don't think there is a major difficulty 
of congestion controlling these text streams. One could use simple 
heuristics principals, like what is outline in 5.4 of RFC 3714. However 
if one is declaring such a heuristic in the specification, you will need 
to have some informative section showing how it is derived.

Finally I would argue that some extra wording in the congestion control 
section is need in regards to pasting text into sessions. I think a 
simple sentence saying:
"When performing congestion control, the real packet sizes MUST be taken 
into consideration. Although most sessions will only contain a few T.140 
symbols per block, there exist possibility for text pasting or automated 
systems to produce significantly larger packets and bit-rates."

In conclusion:
- Reference relevant sections in RFC 3550, 3551, 2198.
- Clarify that congestion control is need in best effort network, even 
though text is small bandwidth.
- Clarify the actions for reducing the bit-rate.
- Put in a note about considerations for pasting and automated systems.

The congestion control section needs to be carefully worded, because 
even a mostly correct, but not completely right sentence, results in 
comments.

See further comments inline.

> Another section of the proposed new edition of RFC2793 takes up congestion
No. as said above.

> based mechanism for text conversation?

No, the thing is that the congestion control people is concerned that 
any new transport stream should not starve out TCP. Therefore there is a 
requirement on congestion control to not allow, for example RTP streams, 
to get significant more bandwidth than what TCP would get in the same 
situation. This is normally referred to as TCP friendly.

In regards to the rest of the discussion, there are work undergoing for 
   defining RTP over TCP, and the necessary signalling in SDP and SIP. 
See draft-ietf-mmusic-comdedia and draft-ietf-avt-rtp-framing-contrans.

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Fri, 16 Apr 2004 13:21:08 +0200

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gunnar Hellstrom
Sent: vrijdag 16 april 2004 10:51
To: Colin Perkins
Cc: [email-masked]; [email-masked]
Subject: RE: [avt] Use of redundancy in rfc2793bis text transmission -
optimizing interoperability

Colin,

Thanks,
Gunnar

-

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 16 Apr 2004 14:10:58 +0200

Magnus, Thanks,

Your suggested action no 3:
3. further increase buffering times beyond 500 ms.
Seems to be the one to prefer, and can also give a good effect.

As said many times already, the amount of increase of load from redundancy,
when we define two redundant generations to be the default, is so minimal
that decreasing to one would have no effect at all on congestion, and
decrease to zero, would be a disaster for the conversation.

In a conversation, if text starts to get through with much longer delays
than normally, the users start backing off, waiting for a response or sign
of life from the others. Since no text is transmitted when no text is
entered this automatically reduces load rapidly. So, in extreme situations
allowing the transmission interval go over the human factors limit of 500
ms would do the job for us.
On the other hand it starts to get dangerous if it happens in an emergency
situation.
I will create some suitable wording.

------------------------------------------
Thanks for the explanation of why TCP was brought into the discussion. My
misunderstanding of the reason caused me to summarize the reasons why we
selected RTP to be the default text transmission environment. We will need
that summary on other occasions.
-----------------------------------------

Gunnar

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Magnus
> Westerlund
> Sent: Friday, April 16, 2004 1:17 PM
> To: Gunnar Hellstrom

---

From: Colin Perkins <[email-masked]>
Date: Mon, 19 Apr 2004 16:08:34 +0100

> conversation, occasionally causing some packets to carry more payload."

I would suggest you also add wording like "Automated systems MUST NOT 
use this format to send large amount of text at a rate significantly 
above that which a human user could enter".

Colin

---

From: Colin Perkins <[email-masked]>
Date: Mon, 19 Apr 2004 16:14:54 +0100

> On the other hand it starts to get dangerous if it happens in an 

I understand your reasoning with regards to emergency situations but 
note that, if you don't reduce your sending rate in response to 
excessive packet loss, the text session will be contributing to the 
loss present on other traffic flows. You have no way of knowing the 
relative importance of those flows: they may also be emergency calls.

There are groups in the IETF working on emergency calling mechanisms 
for VoIP and other calls (e.g. in SIPPING and IEPREP). I would suggest 
that those mechanisms be used for text conversation also.

Colin