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

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

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:adam at nostrum.com] 
Sent: Friday, March 17, 2006 2:09 AM
To: Henning Schulzrinne
Cc: Chris Boulton; Adam Roach; xcon at ietf.org; ajohnston at tello.com
Subject: Re: Why Size Really Can Matter (was Re: [XCON] Conference Control)

[not as chair]

Henning Schulzrinne wrote:

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


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/channe
l[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

_______________________________________________
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