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

Colin Perkins <csp@csperkins.org> Mon, 19 April 2004 15:28 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 LAA16910 for <avt-archive@odin.ietf.org>; Mon, 19 Apr 2004 11:28:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFafQ-0002Lz-Bx for avt-archive@odin.ietf.org; Mon, 19 Apr 2004 11:26:41 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JFQeGe009041 for avt-archive@odin.ietf.org; Mon, 19 Apr 2004 11:26:40 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFaYz-00012m-Fi; Mon, 19 Apr 2004 11:20:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFaWA-0000Ur-E3 for avt@optimus.ietf.org; Mon, 19 Apr 2004 11:17:06 -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 LAA16445 for <avt@ietf.org>; Mon, 19 Apr 2004 11:17:04 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFaW9-00003F-I2 for avt@ietf.org; Mon, 19 Apr 2004 11:17:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFaV9-0007d0-00 for avt@ietf.org; Mon, 19 Apr 2004 11:16:03 -0400
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BFaUl-0007Dm-00 for avt@ietf.org; Mon, 19 Apr 2004 11:15:40 -0400
Received: from alor ([130.209.247.84]:52704) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-SHA:128) (Exim 4.04) id 1BFaU3-0002vD-00; Mon, 19 Apr 2004 16:14:55 +0100
In-Reply-To: <BHEHLFPKIPMLPFNFAHJKIEANEEAA.gunnar.hellstrom@omnitor.se>
References: <BHEHLFPKIPMLPFNFAHJKIEANEEAA.gunnar.hellstrom@omnitor.se>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <500AE5FB-9214-11D8-8F9D-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, toip@snowshore.com
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [avt] Use of redundancy in rfc2793bis text transmission - optimizing interoperability
Date: Mon, 19 Apr 2004 16:14:54 +0100
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
X-Mailer: Apple Mail (2.613)
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=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
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: 7bit

On 16 Apr 2004, at 13:10, Gunnar Hellstrom wrote:
> 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 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


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