Re: [ogpx] Event Streams, Realtime and transport

[Meadhbh Siobhan <[e-mail]>]

experience tells us that real time formats and protocol are a
surprisingly small portion of the solution space. also, the term "real
time" is sometimes used to mean a number of different things. we also
don't have a demonstrated need for real time data, only a perceived
need for it.

i would recommend we say that the definition of "real time" behavior
is "in scope" and give ourselves the option of defining real-time
behavior if needed. an example solution might be the use and
definition of RTP payload formats for delivering object updates. but
let's keep it an option at this point.

having performance characteristics for various transactions is a good
idea, but i don't know that we can mandate performance characteristics
of any transport without introducing QoS. our assumptions up to this
point was that the protocol defined messages that signaled state
transitions and that these messages used REST-like request/response
semantics. that is, the client sent the message and was responsible
for receiving the response. if the response did not come in a
"reasonable" amount of time, the client could repeat it. This is why
REST resource accesses are supposed to be idempotent. We did not
attempt to define the definition of "reasonable" but rather gave that
intelligence to the client.

i think we should be very clear that there's a difference between the
desire that information be transmitted in a low-latency manner and the
requirement that a protocol transaction be "real time." RT(C)P is
designed to carry information that if it arrives too late, is useless.
VoIP is the classic example; if a voice packet arrives too late it is
discarded, you can't integrate it back into the voice stream. many
virtual worlds and MMORPGs do not operate in this fashion today.
instead of discarding late packets, the user experience just seems to
freeze for a few moments followed by a rapid application of messages
received.

additionally, real time data can come over TCP or UDP (i would
recommend keeping SCTP as an experimental option for the time being.)
when it comes as UDP, it frequently has to compete with TCP traffic.
as the network approaches its network rate and packets start
disappearing, it's frequently the UDP messages that suffer the most.
ergo, you'll start seeing real time data disappear. if you send it
over TCP, then you get latency induced by recovering from congestion
control.

so.. in short... we should be EXTREMELY certain that this is what we
want to do. we should also be EXTREMELY certain as to which parts of
the protocol should be given a "real time" option. and we should keep
it an option. for example, defining object updates in terms of RTP
would effectively eliminate a web client using XMLHttpRequest() as
it's primary mode of interaction from accessing state change
information. ditto for XMPP clients.

-cheers
-meadhbh

On Tue, Aug 4, 2009 at 8:32 PM, David W Levine<[e-mail]> wrote:
>
> Based on some discussion after the BOF, i want to offer up the following to
> provoke discussion:
>
> Language to be included in the charter, in the properties of the protocol
> section:
>
> * The protocol needs to support the efficient delivery of asynchronous
> update streams between services,
>     including, specifically between regions and clients.
>
> * The protocol needs to support the processing of real time user inputs and
> low level state changes As part
>    of its work, the working group will characterize the required
> performance, and validate the suitability of
>    transports for these needs.
>
> - David Levine
> ~ Zha Ewry In Second Life
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>