Subject: Re: Text vs. Binary (was Re: Results from the ITU SG16 Berlin)

From: John Segers <[email-masked]>
Date: Fri, 13 Aug 1999 15:41:14 +0200

Jay Batson wrote:

<deleted text including flames>

>
> Oh, and by the way:  those people who are worried about which protocol
> takes less processing power:  Ever heard of Moore's law?  Exactly *HOW*
> long will it *MATTER* whether you handle get 25% more busy-hour call
> attempts by using a binary encoding?  Er, let's see -- doubling, months....
>  It matters for 4.5 months, maybe?

It will _always_ matter whether you can handle 25% more BHCA.  And if
the processing power goes up as predicted by Moore's law, it becomes
more important: 25% of 4 BHCA is only 1 extra, 25% of 1,000,000 is
250,000 extra.

John

>
> My opinions, not my company's.  ;-)
> -jb
>
> ----
> Jay Batson
> Pingtel Corp.
> [email-masked]
> 781-938-5306 (w)

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 344
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Kelvin Porter <[email-masked]>
Date: Fri, 13 Aug 1999 11:04:38 -0500

Just because processing power gets cheaper does not mean that it goes rolled
into the network as soon as the new chips leave the foundry.  You would be
appalled to know how much of the collective GSTN still uses chips that are
literally decades old (e.g., Intel's 8085).

Churning the hardware may not be as easy everywhere, as it is in disposable
consumer electronics (e.g., desktops and PDAs).

Regards,

Kelvin R. Porter

-----Original Message-----
From:   Media Gateway Control (megaco)
[mailto:[email-masked]] On Behalf Of John Segers
Sent:   Friday, August 13, 1999 8:41 AM
To:     [email-masked]
Subject:        Re: Text vs. Binary (was Re: Results from the ITU SG16 Berlin)

Jay Batson wrote:

John

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 16 Aug 1999 01:17:35 -0400

Jay,

> It's quite amazing....  I haven't been aggressively monitoring this list
> for a while.  But last time I did, this same argument (text/binary) was
> going on.  With the same assertions of effiency of processing/programming
> being made by both sides.

Well, just recently, the participants on this list were solicited for their
opinions.  It seems that just a handful of the same folks have stated their
opinion and there was a desire to hear from more people.  Thus, the
discussion you read now.

<snip>

> I would assert that the text/binary choice should be made with an eye
> towards long-term leverage of the context in which the protocol will be
> running:  public IP networks.  In those networks, there are absolutely,
> positively going to be a variety of *other* types of systems invented --
> end nodes, network nodes, etc.  Many of them may be provided primarily for
> *other* purposes than call control, e.g. security, accounting, other
> features/value.

<snip>

> I venture to say it is guaranteed that:
>
> a)  Those "other" systems in the public IP (telephony) networks will be
> running other IETF-defined protocols, 99.9% of which will be text based,
> which means the *developers* of those systems will have system cores /
> parsers / brains / development environments / ... that are geared toward
> text-based protocols.

You did say this was a "long-term" view.  So, is this text encoding going to
be ASCII, UNICODE, or something else? :-)

Actually, I cannot dispute your view that there will be much more text out
there than binary (at least in the number of protocols).  However, we are
focused on one protocol: H.248.  This protocol has a (purposely) limited
scope and equipment manufacturers have certain call handling requirements
that must be met.  The selection of text or binary encoding may or may not
be a real issue-- but people certainly have their opinion.  My concern is
that we are not carefully comparing the two side-by-side for this particular
application.

> b)  It is entirely reasonable to conclude that a significant area of
> differentiation and added value in future releases of our products will
> include tight integration with these *OTHER* systems/products (end nodes,
> network nodes, etc.) on the public IP network.  (Unless you work for an
> elephant....)

yes... and I do not think that precludes creating the best protocol for this
job.

> c)  We should assume the possibility exists that those "other" systems may
> have to parse MEGACO.

yeah..

> d)  Those "other" IP systems/developers are going to be text protocol
> heads.  Reluctant to add the binary (ASN.1) encoding technology that would
> be required for those cases when they must parse MEGACO.

The binary advocates are not necessarily calling for ASN.1 BER or PER
encoding.  The arguments I have heard are that the binary folks feel that a
compact binary encoding will result a protocol that is both faster to
encode, transmit, and decode than a comparable text encoding.  That binary
encoding has not been defined.

> The result:  slower pace of, more complicated, and less rich integration
of
> MEGACO products with other, probably good Internet stuff.

I can't buy that.

> Since the operational context of MEGACO will be public IP networks,
> shouldn't we choose the (text) protocol form most widely used in that
> network/context in order to get the most long-term leverage and
innovation?

Two points:
1) H.248 will not be used only in public IP networks
2) Not all other IP-based protocols (including IP itself) is text-based

Since you're wanting to purge binary protocols, perhaps we should re-draft
RTP as well.  For each audio sample, you could have a "sample=" line with
the value of the sample.  Will they work better with your "other" devices?

> Isn't the whole POINT of this exercise (of re-inventing the PSTN on IP) to
> get some leverage from what NEW possibilities may exist from getting voice
> systems to shed their telecom clothes and wear Internet clothes?

Yes, but we do not aim to make is less effecient.

> (Editorial comment/flame on:)
>
> Why, oh why, are the bellheads forcing ASN.1 on the Internet when the
> Internet has become this major, world-changing force using text protocols
> that work just fine thank you?

The "bellheads" are not forcing ASN.1, although the binary proponents are
pushing for an efficient protocol.  (It should also be noted that even if
ASN.1 were the selected syntax, it does not dictate the encoding.)  And as
mentioned before, the Internet does not run on binary protocols alone.

> CAN'T WE ***JUST SAY NO?***
>
> (Editorial comment/flame off.)
>

Well, given that some companies are going to select a particular hardware
platform with a particular processor, it would be nice to know that on that
given platform, one can handle the highest load possible and not waste too
much time processing whitespace, CRLF pairs, etc.  When it is time for the
next hardware platform, a new processor can be selected, but again-- we
still want to maximize processing.

> My opinions, not my company's.  ;-)

Just my comments and those of a few select companies whose representatives
seem to remain silent for one reason or another.

Paul

---

From: Christian Huitema <[email-masked]>
Date: Tue, 17 Aug 1999 12:53:35 -0400

> more important: 25% of 4 BHCA is only 1 extra, 25% of 1,000,000 is

Handling 25% more calls would certainly be important, but:

1) As Brian Rosen pointed out, the difference in coding/decoding time has
   to be somewhere between -25% and +25%. It could just as well be -5%
   or +8%. 25% is just the end of the envelope, not an actual figure.

2) Encoding and Decoding is only a fraction of the time spend. Encoding
and
   decoding typically touches each message byte once or twice. We also
   want an MD5 checksum, which is somewhat more computer intensive. And we
   want to actually run the call logic, allocate call resources. A 25%
   difference in coding time is likely to turn out something like 2.5% in
   BHCA -- in an MG. In an MGC, one also has to handle per call
accounting,
   routing, advanced services, so that the global importance of encoding/
   decoding is even more reduced -- probably something like 1%, one way
   or another.

3) Systems are provisioned.  A system that has to handle 1,000,000 BHCA
   presumably handles about 100,000 customer lines. The CPU power is the
   least of the problems there, and certainly not a dominant part of
   a system's cost.

4) If a system is debugged faster, it comes to market sooner.  Given a
   lifetime of maybe 5 years, 3 months sooner means a 5% gain...

--
Christian Huitema
------------------------------
Please note my new address: [email-masked]
http://www.telcordia.com/