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

[Adam Roach <adam at nostrum.com>]

[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