FW: Why Size Really Can Matter (was Re: [XCON] Conference Control )

["Brian Rosen" <br at brianrosen.net>]

We seemed to have dropped the list from the cc: in the last exchange.

-----Original Message-----
From: Brian Rosen [mailto:br at brianrosen.net] 
Sent: Thursday, March 16, 2006 2:42 PM
To: 'Sean Olson'
Cc: 'Adam Roach'
Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control )

Clearly, I'm more focused on audio and video for conference control.
I'll admit I have little implementation experience with text.
I think the only media we have is audio, video, text and screen/cursor data.
If you are worried about smell or taste, we have other issues.

While I haven't IMPLEMENTED text, I've used it a fair amount, and I still
don't see the issue.  With "AIM" style IM, you can create a chat room, but,
in my experience, you don't change membership much.

In larger scale chat room (IRC channel) stuff, there is a lot of coming and
going, but it's on the order of one every several seconds; a 1/2 second
delay would be nothing, the semantics of joining or leaving is simple, and
the roster announcement is simple.  I'll agree that in either case, you
don't do much mixer modification on a text media channel.

There is not a lot of experience beyond H.323/T.120 for "data"
(screen/cursor) media that I'm aware of.  Henning has been doing some work.
While I can imagine some "mixer" controls, I would think that you wouldn't
be doing a lot beyond the floor control related stuff (who has the pen?).
OTOH its overall management is pretty simple. 

And, BTW, sidebars are most definitely mixer state for all media I know of.
If you establish a sidebar within a conference, it's the mixer that tells
you what you see/hear when someone sends media to the sidebar.  You only
have a single media stream from the mixer, and you have a single stream to
the mixer (per media type, for most kinds of devices in centralized mixer
conferences).  You tell the mixer whether your media is main conference or
sidebar on media sent to the mixer, and the mixer sends you what you should
get from other participants versions of the same thing.  Unless you plan to
change the RTP connections (or the MSRP mechanism), a sidebar is mixer
state.  For example, unless you plan to signal a separate MSRP connection in
the SDP for a sidebar (which I did not think was in anyone's plan), text
sidebars are mixer state.  Similarly, if you wanted to share a quick sketch
with your sidebar buddy, you would send it to the (single) signaled data
port you have established with the mixer, and your buddy would get it on his
dataport from the mixer INSTEAD OF (not in addition to) the "main
conference" data.   It's the mixer that does this. 

Brian



-----Original Message-----
From: Sean Olson [mailto:Sean.Olson at microsoft.com] 
Sent: Thursday, March 16, 2006 2:09 PM
To: br at brianrosen.net; Adam Roach
Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference Control )

I see the disconnect and this is a really good point to raise. You are
very much focused on mixer management. I am very much focused on
conference management. And it feels to me like a train wreck to force
both into the same protocol if they have such different requirements (in
terms of latency, for example). Your comment that mixer management is
more important or more frequent makes a lot of sense if you are talking
about audio and video only. I think that is a critical use case, but not
the only use case. I'm concerned also about data collaboration, instant
messaging, and host of other non-audio/video media for which "mixing"
takes on a whole new meaning. BTW, in those other media, sidebars are
most definitely not just "mixer state" :-) I can give other examples,
but I get the impression it doesn't matter because those examples apply
to non-audio/video scenarios or at least to true multimedia scenarios.
Is this a goal for XCON? In my experience with these more general
conferencing scenarios, the state notification traffic dwarfs the
conference/mixer control traffic. What is your opinion on how this will
be handled for mobile devices? Will you not subscribe to event
notifications? Will you not care about the latency of those
notifications?


-----Original Message-----
From: Brian Rosen [mailto:br at brianrosen.net] 
Sent: Thursday, March 16, 2006 9:32 AM
To: 'Adam Roach'; 'Drage, Keith (Keith)'
Cc: xcon at ietf.org
Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference
Control )

I agree with Adam.  I keep harping on the operation of setting a value
to a mixer control as the most significant influence on the protocol
design.
Sean (and others) have wanted to talk about richness of conference
establishment.  I don't get it; you establish the call seldom, you
change the mixer often.  We can put up with considerable ugliness on
conference management in exchange for efficient mixer management.  I
don't think the "mixer efficient" protocols are particularly ugly on the
conference management side, but the "conference management rich"
proposals are pretty awful for mixer management efficiency.  

I really do think a mobile client wants to manage its mixer, and the "1
second" cite below is NOT representative of acceptable response to
manipulating a control that is changing what you hear or see.  That
number is in the 100-200 ms range or less, although 500 is not
completely off the wall.  3 seconds is.

Please don't cite sidebar management as a counter-example, or I'll go
back to my argument that sidebars are mixer state.

Brian

-----Original Message-----
From: Adam Roach [mailto:adam at nostrum.com]
Sent: Thursday, March 16, 2006 10:43 AM
To: Drage, Keith (Keith)
Cc: xcon at ietf.org
Subject: Re: Why Size Really Can Matter (was Re: [XCON] Conference
Control )

[not as chair]

Drage, Keith (Keith) wrote:

>I don't remember seeing anybody yet quantifying response times for the
conference control protocol, apart from some mails a while back that
some people seemed to think it could be a replacement for the floor
control protocol.
>

Neither did I, which is why I went through the effort. I quantified the
predicted characteristics of the three proposals being offered.

I also attempted to quantify the requirements somewhat (or, at least,
ask for opinions on the topic) by pondering whether multi-second
response times for adjusting media would be acceptable. If the consensus
of the working group is "yes," then I'm done. I want to make sure the
issue has been considered.

That said, I *do* have an informed opinion on the topic, and I'm happy
to share it.

>For the conference control protocol as I see it at the moment (i.e. 
>with
floor control as an entirely separate protocol) we should be looking for
response times of the same order that we achieve with SIP.
>
I'm not certain this is true. While people are willing to wait multiple
seconds to establish a call, it seems unlikely that they're willing to
wait that long for something they perceive as being interactive, such as
adjusting the volume of a participant. Those kinds of operations
typically carry with them a user expectation of being as close to
instantaneous as possible. That generally means that your time budget
for reaction is on the order of one second or less. See, e.g.,
http://www.useit.com/papers/responsetime.html

>For SIP on 3GPP we found it necessary to mandate SIGComp in order to 
>reduce
message size, and therefore reduce transmission delay, and in a similar
manner with a conference control protocol using XML, we may need to look
at having some compression protocol specified, but we probably do not
need to get any more extreme that that.
>  
>

I believe the situation differs dramatically. By the time the
constraints of mobile terminals were taken into account, the SIP
protocol was effectively set down in stone (or, at least, written in
moist concrete). At that point, the only realistic solutions were
inventing a new protocol or retrofitting compression on top of SIP. I
think choosing to add a compression layer to SIP was the right choice in
this case.

On the other hand, if bandwidth constraints can be considered during the
development phase of a protocol, you prevent issues surrounding such
retrofits. (And they are not without pain -- you'll notice that ROHC is
still struggling with issues surrounding mapping of compression states
to SIP constructs).

/a

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon


_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon


_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon