Subject: RE: Possible new Real-Time Applications and Infrastucture (RAI) A rea

From: "Gray, Eric" <[email-masked]>
Date: Thu, 22 Sep 2005 11:37:04 -0300

Dave,

	Hmmmm.  Someone told me once that real-time means on a
time scale such that no measurable time elapses between event
occurrences and their recognition. You have to allow either
this definition, or one similar to it, as - relativistically
speaking - "real-time" doesn't exist in anything larger than
a Planck length.  So I suspect the another word for real-time
might be ASAP.

	Interestingly enough, we had a number of people talking
about real-time last week in a context where real-time may be
measured in hours or even days.  A classic example is any sort
of production schedule - media, construction, etc.  Another is
bulk transportation - troop movement, shipping, etc.

	Admittedly, in a networking context, real time is being
measured over shorter and shorter time intervals. But the Area
being proposed is not really about networking, is it?

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On Behalf Of
--> Dave Crocker
--> Sent: Thursday, September 22, 2005 1:14 AM
--> To: grenville armitage
--> Cc: IETF list
--> Subject: Re: Possible new Real-Time Applications and 
--> Infrastucture (RAI)
--> Area
--> 
--> 
--> 
--> 
--> > 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.)
--> 
--> 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
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

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