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
- [avt] Use of redundancy in rfc2793bis text transm… Gunnar Hellström
- Re: [avt] Use of redundancy in rfc2793bis text tr… Colin Perkins
- RE: [avt] Use of redundancy in rfc2793bis text tr… Arnoud van Wijk
- [avt] Use of redundancy in rfc2793bis text transm… Gunnar Hellstrom
- RE: [avt] Use of redundancy in rfc2793bis text tr… Arnoud van Wijk
- RE: [avt] Use of redundancy in rfc2793bis text tr… Gunnar Hellstrom
- RE: [avt] Use of redundancy in rfc2793bis text tr… Gunnar Hellstrom
- Re: [avt] Use of redundancy in rfc2793bis text tr… Colin Perkins
- RE: [avt] Use of redundancy in rfc2793bis text tr… Gunnar Hellstrom
- Re: [avt] Use of redundancy in rfc2793bis text tr… Magnus Westerlund
- RE: [avt] Use of redundancy in rfc2793bis text tr… Arnoud van Wijk
- RE: [avt] Use of redundancy in rfc2793bis text tr… Gunnar Hellstrom
- Re: [avt] Use of redundancy in rfc2793bis text tr… Colin Perkins
- Re: [avt] Use of redundancy in rfc2793bis text tr… Colin Perkins
- RE: [avt] Use of redundancy in rfc2793bis text tr… Gregg Vanderheiden