Re: [clue] Timing discussion

[Marshall Eubanks <[e-mail]>]

On Mon, Apr 16, 2012 at 8:47 PM, Brian Baldino (bbaldino)
<[e-mail]> wrote:
> Hey all,
>
> At the last meeting Mary brought up the topic of ‘how quickly do things need
> to happen’ (and therefor where should certain information be carried) came
> up.  I’ve got some text below that is hopefully a good start to that
> discussion; I’m sure there are types of data that I missed but hopefully
> this will work to get things going.
>
>
>
> -Brian
>
>
>
> Timings:
> I’ve categorized these into three levels:
>
> Media plane (typically relatively fast)
> Media control plane (typically relatively medium)
> Signaling plane (typically relatively slow)
>
> The speeds above are just rough categorizations and only describe the planes
> in terms of ‘relative’ speeds as the actual speeds are based on all sorts of
> factors (i.e. even media plane can be ‘slow’ if it’s going over a satellite
> link).

First off, is CLUE really going to set up 3 communications mechanisms
? I hope not.

Second, can we not describe any non-SIP based control channel as being
in the "media plane?" I would prefer "CLUE control channel."

My reasoning here is that there may be "media plane" communications
that occur at a layer below CLUE (e.g., RTCP). Unless we are literally
planning to use that media plane, I don't think we should call what we
are doing media plane.

Third, timings. I think that there are 3 time scales of interest.
These are (roughly, and from a video-centric perspective)

- 30 msec. This is a video frame. Nothing of significance I think can
happen faster, and some things, such as video switching, ideally would
only take one frame.

When I think of "media plane" this is the time scale I am thinking of.
This can only be achieved with one-way communication, as most RTT will
be > 30 msec.

- 200 msec. This was always viewed as the ideal IPTV channel change
time (and a lot of work was done on IGMP to try and get there). This
also happens to be a rough upper bound on non-noticeable RTTs, and so
is a rough  limit on how fast you can do things if those things
require some sort of RT handshake / authorization  / acknowledgement.
I think that it would be good to do many CLUE config changes in this
time range - experience is that users will tolerate 200 msec of
interruption or dead time, if something major changes.

- many seconds. Setting up a conference, changing basic conference
parameters, etc., can take many seconds. Rebooting equipment can take
many seconds.

Things that require, .e.g., noticing that a heartbeat is gone, or that
there is a failure to respond to a message, will also typically take
this sort of time.

Experience is that a many seconds delay may be OK at the start of a
conference, or in case of a major failure, but shouldn't happen very
often if at all inside a functioning conference.

My opinion is that we will not do things on the 30 msec time frame,
that we should set up a CLUE signaling channel, and aim for 200 msec
type performance (when the RTT will support it), and that timing then
becomes a discussion of what is priority, and what is not.
draft-wenger-clue-transport-02 says

At this point in time, there is no proposal on the table  that
suggests that we can avoid a CLUE control channel.

I still think that is valid.

Regards
Marshall

>
> Listed below are some events and the ‘lowest acceptable’ time as listed
> above.  Obviously it is ideal for everything to happen as quickly as
> possible, but, I think what we’re really after is what we would be willing
> to deal with in the worst case.  I don’t have a lot of scenarios, these were
> some things I was able to come up with, but hopefully this ‘system’ will be
> useful to categorize things that come up moving forward.
>
> Image repair (IDR, etc.) – Media control plane
> Layout change – Signaling plane
> Bitrate, etc. renegotiation – Signaling plane
> Switching change (i.e. active speaker) – Media plane
> Roster list – Signaling plane
>
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>