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@standards.nortelnetworks.com Subject: Re: Encoding agreement & Interim meeting
It is not my intent to step into an obviously religious war relative
vs. binary encoding. I would just like to remind the readers on this
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@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
to text list 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)