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

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

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