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: ietf-bounces(_at_)ietf(_dot_)org
--> [mailto:ietf-bounces(_at_)ietf(_dot_)org]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
--> Ietf(_at_)ietf(_dot_)org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf