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

From: Adam Roach <[email-masked]>
Date: Wed, 15 Mar 2006 13:10:34 -0600

(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

---

From: "Sean Olson" <[email-masked]>
Date: Wed, 15 Mar 2006 11:26:45 -0800

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)

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 

  - CCCP: ~1800 bytes
  - COMP:  ~700 bytes
  - CSCP:  ~156 bytes

  - CCCP: ~3.6 seconds
  - COMP: ~1.4 seconds
  - CSCP: ~300 ms

> Have you actually measured the latency for compression? We're probably

> talking 2-3 ms here, based on my experience.
>

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Mar 2006 14:33:25 -0500

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

  - CCCP: ~1800 bytes
  - COMP:  ~700 bytes
  - CSCP:  ~156 bytes

  - CCCP: ~3.6 seconds
  - COMP: ~1.4 seconds
  - CSCP: ~300 ms

/a

---

From: "Sean Olson" <[email-masked]>
Date: Wed, 15 Mar 2006 11:45:27 -0800

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.

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)

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

  - CCCP: ~1800 bytes
  - COMP:  ~700 bytes
  - CSCP:  ~156 bytes

  - CCCP: ~3.6 seconds
  - COMP: ~1.4 seconds
  - CSCP: ~300 ms

/a

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 15 Mar 2006 15:55:44 -0500

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

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)

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

  - CCCP: ~1800 bytes
  - COMP:  ~700 bytes
  - CSCP:  ~156 bytes

  - CCCP: ~3.6 seconds
  - COMP: ~1.4 seconds
  - CSCP: ~300 ms

/a

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Mar 2006 22:46:30 -0500

Jumping into the middle of an interesting conversation...

There seems to be some agreement that delays will matter (mostly) for  
"slider" style operations, such as adjusting the volume. (I'm  
extrapolating here from the examples given.)

For all examples given, only the command delay matters, since the  
command will take effect once the command reaches the server. Thus,  
we can ignore the response size for our calculation, for all protocols.

At least in my view of the SOAPy proposals, we would not convey the  
whole conference state with each request, but rather just the  
parameter you want to change, as in

<CV m="17">80</CV>

for changing volume for channel 17 to 80.

There's a bit of a SOAP wrapper around that, but this is nowhere near  
1800 bytes. I cut-and-pasted this into our SOAP header that got  
generated for our LUMP (ECRIT) prototype by the standard Java SOAP  
library and got 230 bytes without trying hard to minimize namespace  
declaration size.  HTTP is extra, but probably around 50-100 bytes,  
depending on the length of the request URL.

In practice, you can do much better since you can use gzip  
compression in this case, either through HTTP Encoding or below HTTP,  
in TLS. Since the SOAP header is a constant, it will be compressed  
into a 1-2 byte pointer into the dictionary after the second message.  
Indeed, I just tried this: 3 messages of the kind above, with SOAP  
headers, yield a total of 169 bytes, i.e., an average cost per  
message of about 55 bytes. Four messages compress down to 172 bytes,  
i.e., 43 bytes/message. I don't see a need for SigComp here

Thus, in this particular case, XML "wins" the size competition :-)

By the way, does anybody know what happened to the W3C Binary  
Characterization Working Group? The group supposedly closed in April  
2005, but it seems to have petered out earlier, judging from http:// 
www.w3.org/XML/Binary/

Henning

On Mar 15, 2006, at 2:10 PM, Adam Roach wrote:

> (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.
>
>>> */[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.
>
> 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
>
> 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?
>
> 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

---

From: Adam Roach <[email-masked]>
Date: Fri, 17 Mar 2006 01:09:15 -0600

[not as chair]

> for changing volume for channel 17 to 80. 

Excellent. That's more the nature of the conversation I wanted to have: 
considering that size *does* matter, and discussing whether that points 
towards a single solution, or whether any of the other proposals can 
meet the requirement with the proper adjustments.

There's a slight problem with your example, though.

Things like volume adjustments will be performed on the template part of 
the conference object. Considering audio attenuation to be a primitive 
of the conference control protocol goes against everything we've done in 
the model to date. Because templates can be defined after the conference 
control protocol has been carved in stone, the conference control 
protocol needs to have the ability to adjust arbitrary other things.

To give a more concrete (if somewhat silly) example, consider that a 
template in the future may have not just volume controls on every audio 
channel, but also controls that allow users to select from a number of 
voice distortion filters. The goal is that such a template can be 
defined without having to back and add a "change voice distortion 
setting" primitive to the conference control protocol.

Unfortunately, this makes your example something more like:

<C 
path="conference/template/participants/participant[17]/audio/channels/channel[0]/in/attenuation">80</C>

Not a killer, but certainly nowhere near as concise anymore.

The thing that CSCP does that I think is novel is that it allows 
concise, direct access to any changeable element using a unique integer. 
The decision to use BFCP as a transport was simply because it would 
already be implemented in both clients and servers. The same approach 
can be applied to any encoding to reduce the size of messages; if you 
combine this with a concerted effort to make the remainder of the 
messages small, then I think you have a perfectly acceptable solution:

<C e="3281">80</C>

On the other hand, if a request that simply says "ping" ends up as large 
as this:

      <request
          requestId="1"
          from="https://company.com:444/Client"
          to="https://Mcu55.company.com:444/MCU"
          xmlns="urn:ietf:params:xml:ns:cccp"
          xmlns:ci="urn:ietf:params:xml:ns:conference-info"
          xmlns:cis="urn:ietf:params:xml:ns:conference-info-separator"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:ietf:params:xml:ns:cccp cccp.xsd">
              <ping/>
      </request>

Then I believe we need to go back to the drawing board.

/a

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 17 Mar 2006 08:13:39 -0500

Right.

Generally, binary encoded and text encoded protocols are not much different
in size.  We showed that with Megaco.  HOW you express protocol actions is
the thing that matters.

I think the integer idea has merit, and could be applied to any of the
protocols.  It means that you want a "set/get" primitive, and a naming
convention.  For most of the mixer controls, that's about as close to ideal
as you can get, and would also work for any element in a template that has a
simple value.  That covers a lot of ground.  

Compression clearly can help also.  If you are sliding a slider, then even
if you have a large piece of prolog, that would get compressed after the
first time you sent it into some smaller number of bits.  If we do have
compression, I agree we need to design it into the protocol from the get-go.

Brian

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Friday, March 17, 2006 2:09 AM
To: Henning Schulzrinne
Cc: Chris Boulton; Adam Roach; [email-masked]; [email-masked]
Subject: Re: Why Size Really Can Matter (was Re: [XCON] Conference Control)

[not as chair]

<C 
path="conference/template/participants/participant[17]/audio/channels/channe
l[0]/in/attenuation">80</C>

<C e="3281">80</C>

      <request
          requestId="1"

/a