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

"Gunnar Hellstrom" <gunnar.hellstrom@omnitor.se> 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 IAA20448 for <avt-archive@odin.ietf.org>; Thu, 15 Apr 2004 08:50:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6Db-0002sd-9s for avt-archive@odin.ietf.org; Thu, 15 Apr 2004 08:43:47 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FChlvF011052 for avt-archive@odin.ietf.org; Thu, 15 Apr 2004 08:43:47 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE5v0-00048k-L9; Thu, 15 Apr 2004 08:24:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE5f2-0007yd-Pq for avt@optimus.ietf.org; Thu, 15 Apr 2004 08:08:04 -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 IAA18770 for <avt@ietf.org>; Thu, 15 Apr 2004 08:08:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE5f1-0002Qw-00 for avt@ietf.org; Thu, 15 Apr 2004 08:08:03 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE5e5-0002Ny-00 for avt@ietf.org; Thu, 15 Apr 2004 08:07:06 -0400
Received: from mail3.pi.se ([195.7.64.137] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BE5dk-0002Ks-00 for avt@ietf.org; Thu, 15 Apr 2004 08:06:44 -0400
Received: from vit ([217.167.116.106]) (authenticated (0 bits)) by mail3.pi.se (8.12.10/8.11.2) with ESMTP id i3FC47JB004654; Thu, 15 Apr 2004 14:04:11 +0200 (CEST)
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
To: Colin Perkins <csp@csperkins.org>
Cc: toip@snowshore.com, avt@ietf.org
Subject: RE: [avt] Use of redundancy in rfc2793bis text transmission - optimizing interoperability
Date: Thu, 15 Apr 2004 14:06:39 +0200
Message-ID: <BHEHLFPKIPMLPFNFAHJKEENKEDAA.gunnar.hellstrom@omnitor.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <FB711995-8EC2-11D8-9065-000A957FC5F2@csperkins.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id i3FC47JB004654
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none 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

Colin,

You say:
>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?
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
>conversation packet rates and network RTTs, transmission with 20%
>packet loss is TCP friendly (or otherwise)?

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.


You say:
>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.
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
Gunnar.Hellstrom@Omnitor.se
--------------------------------------------


> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Thursday, April 15, 2004 11:55 AM
> To: Gunnar Hellström
> Cc: toip@snowshore.com; avt@ietf.org
> Subject: Re: [avt] Use of redundancy in rfc2793bis text transmission -
> optimizing interoperability
>
>
> On 14 Apr 2004, at 21:59, Gunnar Hellström wrote:
> > 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%)
>
> 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/
>
>



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