Subject: [clue] Timing discussion

From: "Brian Baldino (bbaldino)" <[email-masked]>
Date: Mon, 16 Apr 2012 17:47:27 -0700

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2012 12:09:28 +0200

Hi,

The idea of the draft that I will start working on was to define different criteria for information that needs to be transmitted. Timing is of course one of the most important criteria.

I assume that time critical information in most (all?) cases will have to be sent over the media plane, but I don't think we should have a default assumption that we will automatically send stuff over the signaling plane just because it's not time critical.

Another criteria is whether intermediaries need to have access to the information, which may have impact on how it's sent.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Baldino (bbaldino)
Sent: 17. huhtikuuta 2012 3:47
To: [email-masked]
Subject: [clue] Timing discussion

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:

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

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Apr 2012 09:24:19 -0400

Brian,

I'm having trouble making sense of what you are proposing without some 
numbers attached. For instance its hard for me to distinguish between 
what needs to be in the media control plane and what could be in the 
signaling plane without any estimates of the timing of either, or of the 
required timing. Otherwise I think it simply becomes an exercise of "X 
seems like signaling so it should go in the signaling plane, Y seems 
like media so it should go in the media plane, ...".

Is it possible to put some numeric time ranges on these things?

	Thanks,
	Paul

On 4/16/12 8:47 PM, Brian Baldino (bbaldino) 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
> **
> *Timings*:
> I’ve categorized these into three levels:
>
> 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).
>
> Listed below are some events and the ‘lowest acceptable’ time as listed
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Apr 2012 09:31:24 -0400

On 4/17/12 6:09 AM, Christer Holmberg wrote:
> Hi,
>
> The idea of the draft that I will start working on was to define
> different criteria for information that needs to be transmitted. Timing
> is of course one of the most important criteria.
>
> I assume that time critical information in most (all?) cases will have
> to be sent over the media plane, but I don’t think we should have a
> default assumption that we will automatically send stuff over the
> signaling plane just because it’s not time critical.

As I just replied to Brian, ISTM that it would be helpful to put some 
numbers to the information - expected size, frequency, acceptable 
latency. Also implications of data loss if sent over an unreliable 
channel. Of course all of these numbers will have to be ranges.

> Another criteria is whether intermediaries need to have access to the
> information, which may have impact on how it’s sent.

Yeah, I suppose so.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Brian Baldino (bbaldino)
> *Sent:* 17. huhtikuuta 2012 3:47
> *To:* [email-masked]
> *Subject:* [clue] Timing discussion
>
> Hey all,
>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 17 Apr 2012 09:47:29 -0400

On Mon, Apr 16, 2012 at 8:47 PM, Brian Baldino (bbaldino)
<[email-masked]> 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:
> 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

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