RE: Possible new Real-Time Applications and Infrastucture (RAI)Area

"Yaakov Stein" <yaakov_s@rad.com> Mon, 19 September 2005 10:50 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHJEV-0004Rt-7F; Mon, 19 Sep 2005 06:50:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHJES-0004Ro-H6 for ietf@megatron.ietf.org; Mon, 19 Sep 2005 06:50:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11394 for <ietf@ietf.org>; Mon, 19 Sep 2005 06:50:40 -0400 (EDT)
Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHJJx-0002PV-1d for ietf@ietf.org; Mon, 19 Sep 2005 06:56:31 -0400
Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j8JAlWYL010004 for <ietf@ietf.org>; Mon, 19 Sep 2005 13:47:32 +0300 (IDT)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j8JAlVLx009998 for <ietf@ietf.org>; Mon, 19 Sep 2005 13:47:31 +0300 (IDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Sep 2005 13:51:54 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5205554CB6@exrad2.ad.rad.co.il>
Thread-Topic: Possible new Real-Time Applications and Infrastucture (RAI)Area
Thread-Index: AcW6wYxGY795/+dWTl+u9WSu3RdyrgAKxgaQAIf0suA=
From: Yaakov Stein <yaakov_s@rad.com>
To: ietf@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: quoted-printable
Subject: RE: Possible new Real-Time Applications and Infrastucture (RAI)Area
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I think that setting up this new area is a great idea,
and shows that we are adapting the structure of the IETF
to the applications people now want to use on the Internet.

A few more detailed comments follow.
 
>The Real-Time Applications and Infrastructure Area develops protocols 
>and architectures for delay-sensitive interpersonal communications.

Delay sensitivity impacts communications in several ways.

For setup protocols you want to minimize the number of
round-trips until the user has positive feedback of connectivity status.

For voice and interactive video, delay sensitivity rules out
retransmissions,
and so raises the issue of packet loss concealment.

This in general involves DSP and/or image processing treatments.
For more general data, this means forward error correction
and maximum likelihood estimation of missing data.

These mathematically sophisticated subjects have previously been avoided
in the IETF
(and are awfully hard to present in ASCII ID format).

Is it now proposed to treat these subjects in the IETF, 
and to attempt to draw in audiences interested in so doing?

> >Work in this area serves an emerging industry whose applications and 
> >services include voice and video over IP, instant messaging and 
> >presence. These applications and services are "real-time" in the
sense 
> >that delay impedes human participation in the associated systems.

This is a good characterization of the delay sensitivity problem,
but an unusual definition of "real-time".
Perhaps DSI (delay-sensitive infrastructure) or ISI (Interactive
Services Infrastructure)
more aptly captures the intent.

>The RAI Area is seeded with existing working groups from the Transport 
>and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, 
>ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN.  

I don't really see how GEOPRIV and ECRIT fit in,
based on the delay sensitivity criterion, although they may 
somewhat satisfy the rule of thumb.

My real question is whether the rule of thumb was invented
in order to aid the "seeding" and thus more equitably divide
WGs among areas.

Y(J)S


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf