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

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Sep 2005 10:02:25 +0300 (EEST)

On Fri, 16 Sep 2005, IETF Chair wrote:
> 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.  A good rule of
> thumb for the incorporation of new work into RAI, as opposed to
> Transport or Applications, is that the work in question has major goals
> supporting instant interpersonal communication or its infrastructure.
> For example, they can range from applications to help users make
> decisions about how best to communicate using presence services, to
> session signaling protocols and emergency call routing solutions, to
> work on the "layer five" issues for Internet telephony.

I'm generally sympathetic to this effort.  It would probably help 
focus the transport area (and apps to a degree as well), both for 
real-time and "other" WGs.  It might also help in getting more people 
interested in AD positions when the load is smaller and the 
responsibilities more focused (e.g., SIP folks might not be interested 
in other transport business; "other transport folks" might not be so 
enthusiastic about SIP).

Maybe SIMPLE (from apps area) would also fit in this area?  At least 
from an external point of view, it seems rather close..

I'm not personally so worried about the potential increase of DISCUSS 
ballots.  My personal recollection is that the transport ADs have 
generally been rather focused on the transport business in their 
comments, and evaluating the documents from the perspective of the 
area is very useful.  The more focused the areas are, the better 
chances we have of better and more focused review.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: grenville armitage <[email-masked]>
Date: Tue, 20 Sep 2005 09:43:35 +1000

Short form: I like this idea.

> Real-Time Applications and Infrastucture (RAI) Area Description
>
> The Real-Time Applications and Infrastructure Area develops protocols
> and architectures for delay-sensitive interpersonal communications.

I'm not sure 'real time' is being used here in the same sense it might
be used outside IP communities, but that's a modest nit for now. (I liked
Yaakov Stein's "Interactive Services...." variant, though.)

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

I think it would be nice to see explicit mention of delay-sensitive, online,
single|multi-player games.

To an extent that industry has 'rolled their own' protocols for server
discovery, client registration, patch/maps/mod download and upload,
lag/loss estimation and compensation, embedded voice channels, encoding
of player action streams (commands) and game world state updates
(snapshots), etc.

I'm not sure if there's a demand (yet) for any IETF WG to develop common
protocols and architectures for delay sensitive multi-party/player games,
but it would at least be worth flagging the possibility in the new Area's 
description. (There's certainly been a small yet active community of
people studying how current and previous 'home brew' multiplayer game
protocols impact on networks, with papers at various workshops and
conferences over the past few years.)

cheers,
gja
-- 
Associate Professor Grenville Armitage
Director, Centre for Advanced Internet Architectures
http://caia.swin.edu.au

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Sep 2005 22:14:21 -0700

> Yaakov Stein's "Interactive Services...." variant, though.)

This highlights one of the points of confusion about the current proposal:
the idea for the area seems to be getting defined in terms of some performance
constraints, but the constraints are fuzzy, at best.

Historically, the term "interactive" refers to human tolerances, with the most
interesting threshholds being at 1/2-second and 2 seconds.  The term
"real-time" tends to mean sub-second, and often much faster than that.
However much of the focus is on streaming, where the focus is on inter-packet
jitter, rather than the amount of time it takes for the first packet to show
up, or even for round-trip time.

And, by the way, just what is it that makes instant message and presence need
performance characteristics that are any different from http, DNS, or numerous
  other "interactive" protocols?

All of this leads to the larger problem that the proposed area appears to
desire to stovepipe integrated work on several layers.  The one thing this is
sure to achieve is an eventual failure to integrate with other uses for shared
layers.  By definition, the folks in the new area will not be worrying about
cohabitation; they will focus on on the needs of their own set of applications.

When we start having specialized applications dedicated for shared
infrastructure, that clever hour-glass is going to lose its shape...

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Melinda Shore <[email-masked]>
Date: Thu, 22 Sep 2005 08:01:27 -0400

On 9/22/05 1:14 AM, "Dave Crocker" <[email-masked]> wrote:
> The term

That seems to be the vernacular use, but strictly speaking "real-time"
is about robust assurances of delivery within a constrained time period,
whether that time period is millisecond or multi-minute.  In other
words, the focus is on the guarantees, not on really-really-fast.

> By definition, the folks in the new area will not be worrying about

I don't agree that it will happen "by definition," but in any event it's
already happening anyway.  That there's effectively only one AD covering
the area at the moment may have something to do with that, or maybe not.
Also, for some of these applications, it's increasingly the case that
they're not running on a shared infrastructure.  Whether through the
use of physically separate networks or through engineered tunnels, things
like voice are starting to run on at least logically isolated networks.

Melinda

---

From: Dave Crocker <[email-masked]>
Date: Fri, 23 Sep 2005 14:38:05 -0700

Melinda, et al,

>> "real-time" tends to mean sub-second, and often much faster than that.

Vernacular is not usually *more* precise.  Note that I cited (human) 
interactive vs. real-time, with whereas the usage you describe one terms that 
encompasses both.

The discussion at <http://www.faqs.org/faqs/realtime-computing/faq/> 
demonstrates that the term is indeed pretty fuzzy.

Still, yes, it's clear that recent use of the term real-time has tended toward 
the more generalized model in your description, referring to anything that is 
time bounded by external constraints.

For the proposed area, that does not seem to explain the inclusion of  ENUM, 
instant messaging or presence.  (This area is going to take over xmpp, too?)

Certainly none of those have performance constraints that are significantly 
different from DNS, HTTP, Telnet, SNMP or a number of other protocols.  Nor do 
they reflect a signaling/transfer model split, as per Ted's revised language.

So the technical basis for this new area remains fuzzy.

>     Whether through the

In which case this is not a new area, but is a new task force, since isolation 
means it is not part of the standard Internet architecture.

Either the effort needs to be seriously coordinated with the rest of the IETF 
work or it doesn't.  If it does, then particularly the infrastructure work 
needs to be done along with related infrastructure work.

Since the bulk of the basis for providing time-bounded response times is 
almost certain to involve underlying infrastructure changes, then either the 
changes must be done AS PART OF the full Internet infrastructure technologies, 
or it must be done as a completely separate community and service.

The idea that this new area will make changes to, say, IP, without being part 
of the Internet area just does not make sense.

d/

-- 

  Dave Crocker

---

From: Melinda Shore <[email-masked]>
Date: Fri, 23 Sep 2005 17:56:16 -0400

> instant messaging or presence.  (This area is going to take over xmpp, too?)

ENUM is ancillary to telephony and not really to much else.
But anyway, you'll note that I argued that "real-time" is
an unsuitable name because of what it actually means, not
that your definition of real-time was vernacular and we need
to focus on what's actually real-time.  I tend to prefer
naming it something around multimedia applications but as
long as whatever it is is reasonably descriptive and won't
lead to people thinking that it's a proper place to work
on things like storage device controllers, I'm good.

Melinda

---

From: Dave Crocker <[email-masked]>
Date: Fri, 23 Sep 2005 15:59:31 -0700

Melinda, thanks for pursuing this.

 >  I tend to prefer

well, what I was in fact trying to get at was the need for characterizing the 
technical work, unless this really is merely splitting off a piece of apps 
work according to an interest group.  If there are distinguishing technical 
characteristics to the work being done, then its nature needs to be clear.

So far, references have been made to time-sensitive and to signalling, yet it 
is not clear how this applies to the work that is being defined as seeding the 
area.  Since SIP is really a signalling protocol, yes, that part is clear. 
But where is the time-sensitive technology component to the work in the area?

And if it is "multi-media" then what does that really mean?  Note that email 
and the web are multi-media... big time.

d/
-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 23 Sep 2005 16:02:42 -0700

Adam Roach wrote:
> Dave Crocker wrote:
> 
>> (This area is going to take over xmpp, too?)
> 
> 
> I don't think it is a useful exercise to go through all the closed 
> working groups to determine which would have been in RAI had the area 
> existed when they were still active.

i agree.  so it's probably a good thing I didn't.

by the same token it does not make sense to include work that seems to have no 
relationship to the various (and varying) stated technical criteria.

Therefore, mentioned parallel work -- whether active or completed -- by way of 
demonstrating an implication, did, and does, seem useful.

d/

-- 

  Dave Crocker

---

From: Scott Michel <[email-masked]>
Date: Sat, 24 Sep 2005 00:27:40 -0700

> words, the focus is on the guarantees, not on really-really-fast.

Let me play Devil's Advocate for a second: What wasn't addressed by the
previous work done in RSVP and Diffserv that this new area has to be
urgently addressed? Are not packet schedulers enough?

Or are we going to watch a whole new infrastructure get developed that will
be now better than the previous work, with less complexity, and more hope of
being deployed outside of DoD programs? Because, frankly, that's the only
place I've seen an explicit need for advanced QoS techniques (besides VoIP,
and that gets to be really debatable too.)

-scooter

---

From: Pete Resnick <[email-masked]>
Date: Sat, 24 Sep 2005 11:15:51 -0500

On 9/23/05 at 3:59 PM -0700, Dave Crocker wrote:

>So far, references have been made to time-sensitive and to 
>signalling, yet it is not clear how this applies to the work that is 
>being defined as seeding the area.  Since SIP is really a signalling 
>protocol, yes, that part is clear. But where is the time-sensitive 
>technology component to the work in the area?

Dave,

I'm not entirely clear here: Do you have a problem with Ted's 
reformulation of this potential new area as the Signalling 
Applications and Infrastructure Area? That is, does his description 
concretely define the new area well enough?

(If SAI is reasonable, and I think it is, let's use that 
reformulation and be done with it.)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

---

From: Scott W Brim <[email-masked]>
Date: Sat, 24 Sep 2005 16:41:22 -0400

> reformulation and be done with it.)

Hi.  I'm just catching up but I think "signaling" is not an essential
discriminator of what we're talking about, and thus this name is in
fact unreasonable.  Some relationships are established or tailored
through signaling that have nothing to do with interactiveness or
delay tolerance (or SIP).  Some are established through "management".  

"Delay-sensitive interpersonal communications" seems to be an
excellent description of the scope.  "Instant" messaging should be
included.  TDM should not, and one-way multimedia should only be
ancillary, even if SIP-based.  

I'm not sure what the name should be but please, putting "signaling"
in the name is worse than "real-time".

swb

---

From: Pete Resnick <[email-masked]>
Date: Sat, 24 Sep 2005 17:02:51 -0500

On 9/24/05 at 4:41 PM -0400, Scott W Brim wrote:

>>Signalling  Applications and Infrastructure Area

Actually, I screwed up: It's "Signalled Applications and Infrastructure".

>Some relationships are established or tailored through signaling 
>that have nothing to do with interactiveness or delay tolerance (or 
>SIP).

True, but which "Signalled Applications" are you thinking of that 
wouldn't fit into this area? Further, I can think of all sorts of 
interactive and delay intolerant things that do not belong in this 
area. *Signalled* applications (and the infrastructure to support 
them) seems *exactly to describe the things that I want grouped 
together.

>Some are established through "management".

I don't understand. Are you saying that protocols with "managed" 
relationships which aren't signalled do belong in this area (and that 
"signalled" in the name would muddy the waters somehow)? Could you 
give me examples?

>excellent description of the scope.

(*Shrug*) "Interpersonal" doesn't seem to apply to some things I want 
in this area (as I think has been mentioned before.

>"Instant" messaging should be included.

Right.

>TDM should not...

And TDM is a "signalled application"?

pr

---

From: Adam Roach <[email-masked]>
Date: Fri, 23 Sep 2005 17:10:47 -0500

/a

---

From: Richard Shockey <[email-masked]>
Date: Wed, 28 Sep 2005 05:21:38 -0400

Melinda Shore wrote:

ENUM's only reason is map E.164 numbers to URI's which in 99.9 % of the
cases means VoIP.

ENUM's very existance is totally linked to the rest of the SIP
applicaiton suite and as such needs to remain with the rest of those
groups.

I thought the original proposal was pretty good and needed little or no
editing including hair splitting on what the name of the directorate
should be.

Real Time Applications is a pretty good descritpion of the general
problem set or maybe  "Death to the PSTN Directorate?" .

can we just get on with it ?

Melinda

--

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<