I would agree with Bob below in that the vast majority of
telecommunications
networks binary is used as an encoding method, its efficient, its
tested, debugged and interoperates but as mentioned elsewhere they're
old arguments but VERY valid.
I think we need to understand the scope of the H.GGP/248 protocol. Its
not just H.323 or SIP networks. The media controller and media gateway
architecture and the 'vertical protocol' which it infers has now been
adopted by many groups/forums. These include:
o MSF who have previously put in requirements on this group
o SG16 H.323
o ITU SG11 are working on Bearer independant call control BICC which
will need a vertical protocol in the near future
o ANSI T1S1 BICC
o ETSI SPS1 BICC
o Will be used in 3rd Generation Mobile networks
These groups have successully worked with binary protocols.
o IETF MMUSIC SIP
Work with text.
o Cable labs <- already chosen MGCP???
o Switch Switch <- already chosen MGCP
I think that we should be looking at the medium to long term future
of this protocol. If it is to be WIDELY adopted by all groups above
then we should be looking at the efficiency and interwork reasons
primarily NOT that it only takes 2 weeks, 10 pizzas and a 6 pack to
implement and its easy to debug at 3 in the morning.
I also think that it is unwise to let a 'toss of a coin' decide the
direction that was taken with regards to encoding on H.HCP/248 in this
light.
Regards, Christian
Bob Bell wrote:
>
> Brian -
>
> Comments below.
>
> At 04:06 PM 7/19/99 , Brian Rosen wrote:
> >Sorry, you just indeed walked into the sticky part.
> >
> >There are claims that in fact, the text encoding is SMALLER than
> binary
> >encoding for
> >the kinds of messages we will encounter. This is based on
> observation of
> >similar
> >protocols.
>
> There may in fact be such claims but in the various communications
> protocols I have personally dealt with, it has not been the case.
> If someone could point me to some observational data, I would be most
> grateful. However, I it still my considered opinion, at this time,
> that there is a bias in size toward the text based messaging having
> more octets of information.
>
> >
> >Our current consensus opinion is that the difference is almost
> certainly in
> >the +/- 20% range. That would make encryption arguments pretty
> moot.
>
> A 10% bias, that being the median of your count, means that you can
> support 10% less control streams or that your cost is increased 10%
> per control stream. That seems to be a significant number to me.
> Particularly in the realm of high density environments.
>
> >
> >I assume you did not mean to suggest that text was any more or less
> secure;
> >just that
> >if the messages were bigger, the encryption load would be bigger.
>
> I agree that there is no diference in the "security" aspect of text vs
> binary.
>
> >
> >I will point out that encryption is done over a fixed size datum,
> typically
> >8 bytes.
> >Thus the increment of encryption work is not simply linear. If you
> have 9
> >bytes, it
> >takes as long to encrypt 10, 11, 12, ... or even 16 bytes (assuming
> DES).
> >Small
> >variations thus have even less effect on encryption speed.
>
> Assuming that you are correct that the message length is 10% longer
> for one form of message. If a typical message is on the order of 100
> octets in length (in view of the Megaco packaging into transactions
> and contexts, this is not an unreasonable number), and assuming that
> you are using a DES style encryption which uses a block size of 64
> bits or 8 octets, a 100 octet message must be padded to be 104 octets
> in length. This requires 13 complete encryption blocks. Adding an
> additional 10 octets increases the number of blocks to 14. That is a
> 7.7% increase in encryption blocks. While this is no the 10% discussed
> above, it is still non-trivial in a large volume project where the
> cost is a high consideration.
>
> >
> >Brian
> >
> >
> >-----Original Message-----
> >From: Bob Bell [mailto:rtbell@cisco.com]
> >Sent: Monday, July 19, 1999 5:43 PM
> >To: MEGACO(a)standards.nortelnetworks.com
> >Subject: Re: Encoding agreement & Interim meeting
> >
> >
> >It is not my intent to step into an obviously religious war relative
> to text
> >vs. binary encoding. I would just like to remind the readers on this
> list
> >that for the purposes of privacy and security on the control
> channels, text
> >messages typically contain more octets of "plaintext" which must be
> >encrypted and decrypted than do binary messages containing the same
> level of
> >control information. While for workstations and similar devices, this
> load
> >may be perceived as being a trivial addition, if you are making an
> MGC and
> >are planning to have hundreds or perhaps thousands of simultaneous
> control
> >streams active, the additional processing requirements may not be as
> easily
> >ignored. Perhaps this is a reason to consider the binary encoding
> scheme in
> >a somewhat more favorable light.
> >
> >At 02:44 PM 7/19/99 , you wrote:
> >>Matt, first off, I suspect you are still talking about the media
> descriptor
> >>and media capability descriptor components of the protocol. We have
> agreed
> >>that for these components, each group will use its own encoding,
> implying
> >>that the MGC must support both. As for the encoding beyond these
> two
> >items,
> >>the conclusion we came to in the "ad hoc" meeting was that Megaco
> and SG 16
> >>would always disagree on this issue. There doesn't seem to be any
> way to
> >>create a higher synthesis, as we could with the context connection
> model.
> >>As a result, the only way we could meet each other half way was to
> have an
> >>equal probability that one solution or the other would be chosen. I
> would
> >>have preferred that the coin flip be done in a combined SG 16/Megaco
> >>meeting, but we had the next best thing: both Glen Freundlich (the
> SG 16
> >>rapporteur responsible for H.248) and I were there.
> >>
> >>> -----Original Message-----
> >>> From: Michael Thomas [SMTP:mat@CISCO.COM]
> >>> Sent: Monday, July 19, 1999 3:18 PM
> >>> To: megaco(a)standards.nortelnetworks.com
> >>> Subject: Re: Encoding agreement & Interim meeting
> >>>
> >>> Matt Holdrege writes:
> >>> > I guess too much is happening in the design team meetings then.
> Well
> >>> it's
> >>> > out in the open on the list now. I'll put forward that the TLV
> >>> structure
> >>> > (which allows everything that each side needs) is the best way
> to
> >>> achieve
> >>> > consensus between the IETF and ITU. If we drive too far in
> either
> >>> > direction, we are not following our directive.
> >>> >
> >>> > Since as you and others say that there is no major difference
> between
> >>> text
> >>> > or binary, why not choose binary since it is the format that
> the ITU
> >>> really
> >>> > wants and is quite used to.
> >>>
> >>> Well, text encodings is what IETF "wants and is
> >>> quite used to." There are good reasons to use text
> >>> such as ease of implementation, debugging, and
> >>> interoperability. Thus far nobody's put out any
> >>> compelling advantage of a binary encoding over a
> >>> text encoding.
> >>>
> >>> > The result is that we will have a single interoperable standard
> and no
> >>> one
> >>> > can say that it presents any engineering problems. Right?
> >>> >
> >>> > Since you've chosen text in this ad-hoc meeting, you are almost
> >>> > guaranteeing lack of a single standard.
> >>>
> >>> Let me understand this: are you saying that if
> >>> text encoding of the MEGACO *protocol* is choosen
> >>> (as it was), that SG16 will pick up its toys and
> >>> go home?
> >>>
> >>> Mike
> >
> >Bob Bell
> >Distinguished Member of the Technical Staff
> >Cisco Systems Inc.
> >801-294-3034(v)
> >801-294-3023(f)
> Bob Bell
> Distinguished Member of the Technical Staff
> Cisco Systems Inc.
> 801-294-3034(v)
> 801-294-3023(f)
