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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 16 Mar 2006 14:18:08 -0000

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. On the floor control protocol, I would expect good round trip response times to the user.

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

Incidentally I do not think that H.323 is a good example to use for ASN.1 usage. H.323 uses just about every coding scheme going, quite frequently in the worst possible manner, and in many respects I see the usage of the packed encoding rules as adding to that.

regards

Keith

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: 15 March 2006 20:56
> To: 'Sean Olson'; 'Adam Roach'; 'Henning Schulzrinne'
> Cc: 'Chris Boulton'; 'Adam Roach'; [email-masked]; [email-masked]
> Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference
> Control)
> 
> 
> Extending the mechanism is part and parcel of the job; we 
> have a notion of
> template, it's an XML data structure, and you can create all 
> sorts of nifty
> extensions by creating an XSD.
> 
> The ON THE WIRE protocol that manipulates the template 
> doesn't have to be
> xml itself to get the advantages of that.  I don't especially 
> want a lot of
> extensions to the on-the-wire part; if we have done our job 
> correctly, the
> template captures the range of extensions we need.
> 
> I'll agree that debugging the on-the-wire bits is easier with 
> a text based
> protocol that with a binary one.  I'll agree that if COMP or 
> C3P pushes down
> the number of bits for real use cases (which would NOT 
> include any fixed
> dictionary things) to the range of CSCP then there isn't a 
> good argument for
> binary encoding.  I too much prefer SIP to H.323.  I was part 
> of the Megaco
> binary/text arguments and we showed that there was not a great deal of
> difference between the number of bits for the common 
> operations in ASN.1 and
> text encodings, which favored a text encoding.  So far, the 
> evidence I've
> seen shows we aren't in the same ballpark here, and we do 
> want bandwidth
> restricted devices to work well.
> 
> So, it seems to me that you are saying that the ease of 
> development and
> debugging is more important than supporting bandwidth 
> restricted clients.  I
> don't think you get any significant advantage for development 
> ease, you do
> get some advantage for debugging, and the tradeoff, if there 
> is one, should
> favor supporting bandwidth restricted devices.
> 
> I'd really rather see you show that text encoding isn't any 
> substantial
> difference in size, rather than arguing the other advantages of text.
> 
> Brian
> 
> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]] 
> Sent: Wednesday, March 15, 2006 2:45 PM
> To: [email-masked]; Adam Roach; Henning Schulzrinne
> Cc: Chris Boulton; Adam Roach; [email-masked]; [email-masked]
> Subject: RE: Why Size Really Can Matter (was Re: [XCON] 
> Conference Control)
> 
> I look at the difference as being ASN.1 vs. XML (bear with me :-) 
> 
> Using XML has a lot of advantages in terms of implementation and
> expressiveness. You can achieve the same sort of thing with ASN.1. But
> there are obviously some differences in the way you would approach
> extending each and implementing each. In a CPU and bandwidth 
> constained
> device, I too would want a optimized binary protocol with a very tight
> data structure. In a richer conferencing device, I want to deal with
> technologies that I'm already implementing and which I feel very
> comfortable in extending. XML is a lingua franca for a lot of
> applications today. It has its warts, but if I show an XSD to most
> developers today, they "get it" and can get up and running quickly.
> PLUS, they are comfortable with how to rapidly extend and 
> prototype new
> applications built on top of this base. Not to mention all 
> the toolsets
> already in the marketplace today to make this sort of thing 
> trivial. I'm
> not saying you can't do any of this with CSCP, it's just not my
> preferred approach when I have device which has ample CPU power,
> bandwidth, and the toolsets to make something like COMP or C3P work.
> This is very similar to ASN.1 vs XML/text and why I like SIP so much
> better than H.323 :-) 
> 
> 
> 
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Wednesday, March 15, 2006 11:33 AM
> To: Sean Olson; 'Adam Roach'; 'Henning Schulzrinne'
> Cc: 'Chris Boulton'; 'Adam Roach'; [email-masked]; [email-masked]
> Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference
> Control)
> 
> I'm sorry, but I don't quite get this.  Are you saying that 
> CSCP somehow
> hobbles devices that are multimedia endpoints consuming oodles of
> bandwidth?
> 
> I'd agree with your sentiments if there was actually a substantive
> difference in what you can DO with the protocols.  Right now, while
> there are some very clear model differences, as well as very clear
> encoding differences, I don't see a lot of expressiveness differences.
> 
> If you see some, would you point them out to me?
> 
> Brian
> 
> 
> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2006 2:27 PM
> To: Adam Roach; Henning Schulzrinne
> Cc: Chris Boulton; Adam Roach; [email-masked]; [email-masked]
> Subject: RE: Why Size Really Can Matter (was Re: [XCON] Conference
> Control)
> 
> This is a great analysis of why we have to be mindful of bandwidth and
> processing on mobile devices. Now let's talk about why limiting every
> device that wants to do conferencing to these same constraints may not
> make sense. 
> 
> First, there is multimedia where you won't always be able to 
> squeeze the
> media into 4Kbps (or want to). This includes many video codecs,
> application sharing, file exchange, etc.
> 
> Second, there are advanced conferencing applications which may require
> truly intelligent endpoints (pushing the 100MHz envelope ;-). Examples
> include application sharing for CAD/CAM, advanced cascading
> architectures, bots as moderators, gaming, etc. 
> 
> Third, there are many conferencing scenarios that may not involve a
> mobile device at all. Of course these scenarios can benefit from the
> reach of mobile technology, but there are simply cases where a mobile
> device does not fit. Examples include conferencing capabilities
> integrated with factory processes, web conferencing for B2C, customer
> service kiosks, etc.
> 
> I'm very much in favor of designing a protocol which works and makes
> sense for mobile devices. I don't want to hobble the rest of 
> the system
> in order to make this work. Could we do two different encodings of the
> same base protocol?
> 
> 
> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2006 11:11 AM
> To: Henning Schulzrinne
> Cc: Adam Roach; Chris Boulton; [email-masked]; [email-masked]
> Subject: Why Size Really Can Matter (was Re: [XCON] 
> Conference Control)
> 
> (not as chair)
> 
> Because I've spent an inordinate amount of time over the past 5 years
> working with issues surrounding mobile terminals, signaling size,
> latency, and compression, I wanted to throw in a couple of relevant
> points on the topic of message sizes.
> 
> Henning Schulzrinne wrote:
> 
> >> */[Chris Boulton] I get the handset bandwidth - I have heard it in 
> >> almost every IETF meeting I've been to + I also agree it's a major 
> >> consideration BUT lets not just keep harping back to it./*
> >>
> >
> > This is largely a bogus argument. In any multimedia conference, the 
> > control bandwidth is going to be a tiny fraction of the overall 
> > bandwidth consumed by media.
> 
> 
> Right now, more than one major US wireless carrier has deployed voice
> services over their existing data networks, which nominally 
> pass 9.6kbps
> of data; once you factor in overhead, the real data 
> throughput of these
> data connections is on the order of 8kbps. (I use these 
> carriers as data
> points because I'm familiar with them; I would guess that similar
> deployments have been made in other countries as well).
> 
> In order to pass voice over these connections, carriers are generally
> using codecs like half-rate EVRC, which consumes 4kbps. This leaves on
> the order of 4kbps to perform signaling.
> 
> Using the examples in the CCCP, COMP, and CSCP proposals, a
> representative request/response exchange takes on the order of the
> following sizes:
> 
>   - CCCP: ~1800 bytes
>   - COMP:  ~700 bytes
>   - CSCP:  ~156 bytes
> 
> Over the 4kbps available on these actually deployed voice 
> systems, these
> exchanges will take the following amounts of time:
> 
>   - CCCP: ~3.6 seconds
>   - COMP: ~1.4 seconds
>   - CSCP: ~300 ms
> 
> This raises an issue around how long users will be willing to wait
> between requesting an action and it taking effect. Is it okay 
> for it to
> take several seconds to adjust a volume level or mute a participant?
> 
> > Have you actually measured the latency for compression? 
> We're probably
> 
> > talking 2-3 ms here, based on my experience.
> >
> 
> For the middle-of-the-line mobile terminals in wide use today 
> (~100 MHz
> processors), running deflate over a 1kb message (the order of messages
> we're talking about here) is on the order of 100 ms. Not 
> outrageous, but
> 
> not trivial. The bigger issue by an order of magnitude is the 
> fact that
> doing this on the CPU requires 100% CPU utilization during this time
> period, which impacts battery life probably more than you 
> would expect. 
> (700 mAh doesn't take you too far when it's expected to last several
> days).
> 
> /a
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 Mar 2006 09:43:28 -0600

[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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 16 Mar 2006 12:31:40 -0500

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:[email-masked]] 
Sent: Thursday, March 16, 2006 10:43 AM
To: Drage, Keith (Keith)
Cc: [email-masked]
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.

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

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

/a