Subject: Re: Text vs. Binary vs. common sense

From: Kelvin Porter <[email-masked]>
Date: Fri, 13 Aug 1999 10:56:20 -0500

David,

Thank you for your response. Comments interleaved below...

-----Original Message-----
From:   Media Gateway Control (megaco)
[mailto:[email-masked]] On Behalf Of David Israel
Sent:   Thursday, August 12, 1999 7:26 PM
To:     [email-masked]
Subject:        Text vs. Binary vs. common sense

Kelvin I appreciate your effort but I don't think you are going to make much
Progress

I can accept this...  I just felt that the skirmishing over encoding forms
and message syntax specifications is completely irrelevant and the arguments
advanced to defend one side or the other really pointed to a more
significant issue.  What we are trying to formalize is a set of
communication semantics between two control (systems with one or more)
processes (i.e., MGC instance and MG instance).  A modern programmer would
not waste time re-inventing RPC mechanisms.  Ultimately, the semantics
(poorly captured as message specifications) will be constructed within a
programmatic interfaces.  It would behoove all the people who must write the
code to enable these transactions, if there was only one programmatic
specification to use.  If I can make an unfair comparison, it is the
difference between having to write a SS7 stack before you use it and using a
standardized TCP/IP library.

Growing forces insure that these are issues that the IETF and ITU are
eventually going to have to deal with.

 without challenging people to produce call flows for more specific
services.

Not to be obtuse.  But I do not understand what you are trying to say here
(unless you are talking about MGC-MG object interaction diagrams (OIDs) ).

The real point of mechanisms 1 - 3 below is that they allow
execution of simple to program service logic on another box without passing
a thousand standardized messages.

I challenge the description simple.  They are sufficient to encode any
transaction that can be described via a protocol.  With that said, it just
so happens that Megacop's control semantics are relatively simple.

The more messages (or variants) the stronger the need to automate the
specification of the syntax and coding of the encoding, decoding,
marshalling, and de-marshalling.  That is precisely what the recommended
mechanisms do for you.

On the other hand a thousand standardized messages may be exactly what some
members of this mailing list would relish.

Or a handful of  messages, each with hundreds of variations.

Does anyone ever respond to your
posts besides me?

We were laughing about that just yesterday... You are one of a blessed
few... :)

Regards,

Kelvin R. Porter

David

-----Original Message-----
From: Kelvin Porter <[email-masked]>
To: [email-masked]
<[email-masked]>
Date: Wednesday, August 11, 1999 11:50 AM
Subject: Re: Text vs. Binary (was Re: Results from the ITU SG16 Berlin mtg)

>With regards to reducing programmers efforts, there are several methods
that
>clearly work better than protocol specifications (whether text- or
>binary-encoded).
>1. Middle-ware (e.g., RPC Mechanisms & ORBs)
>2. Portable Software Libraries (e.g., Java Libraries)
>3. Raw Scripting (e.g., Java RMI)
>
>All of these techniques offer the advantage of allowing the developer to
>focus on the semantics of the transactions while ignoring the issues of
>encoding, marshalling and de-marshalling, etc.
>
>With regards to efficiency...
>Each of these techniques can be very performant.  Several telecom equipment
>vendors have equipment that implement various forms of middle-ware.  At
>least one or two use raw scripting.  Obviously, there are protocol stack
>vendors, e.g., Trillium, DGM&S, etc.
>
>It would be refreshing to focus on the control paradigm as encoded in some
>programmatic API rather than attempting evaluate and disambiguate based on
a
>protocol specification.
>
>Regards,
>
>Kelvin R. Porter
>
>-----Original Message-----
>From:   Media Gateway Control (megaco)
>[mailto:[email-masked]] On Behalf Of Paul E. Jones
>Sent:   Tuesday, August 10, 1999 8:59 PM
>To:     [email-masked]
>Subject:        Re: Text vs. Binary (was Re: Results from the ITU SG16
Berlin mtg)
>
>Folks,
>
>I think this is a rather interesting discussion...
>
>The costs discussed here are entirely on "how much work does the programmer
>have to do".  I realize that cost is an issue, but so is performance.  I
>have not yet been able to convince myself that a text encoding is going to
>be *tremendously* easier and I have certainly not been able to convince
>myself that text is going to be more efficient.  In my opinion, if the
>programmer has to work just a little harder to get the job done, that
should
>not be the reason for selecting one thing over another.
>
>While I realize that the IETF has chosen text encoding by using the
>scientific method of coin tossing, I believe the concerned folks at the ITU
>want to engineer a protocol that will process the highest number of calls
>per second-- after all, that is what will sell.  Now, ASN.1 BER or PER may
>not be the right answer, either.  However, several people at the last SG16
>meeting felt strongly that a binary encoding would result in a faster
>protocol.
>
>I believe that the IETF and the ITU have mounds of evidence that show that
a
>binary encoding can be fast and efficient.  Do we have such evidence for
>text encoding?  Do the proponents of text encoding feel that text will
allow
>them to get the higher number of calls per second through their MGC?  Do
>they care?
>
>Paul
>
>----- Original Message -----
>From: Brian F. G. Bidulock <[email-masked]>
>To: <[email-masked]>
>Sent: Tuesday, August 10, 1999 3:31 AM
>Subject: Re: Text vs. Binary (was Re: Results from the ITU SG16 Berlin mtg)
>
>
>> Vikas,
>>
>> Here are my comments on cost comparisons.  Bottom line?--little to no
>difference.
>>
>> [email-masked] wrote:
>>
>> > [snip]
>>
>> > I would like to have clarification on some cost related issues. Which
of
>the two options
>> > would be more cost-effective for the implementor?
>>
>> Well, that depends on the implementation of course.  I cannot speak for
>commercially available
>> text parsers, but I can speak somewhat for ASN.1 encoder/decoders.
>>
>> > How much does the run-time library of an ASN.1 encoder/decoder cost per
>installation and how
>> > much does the run-time text parser cost per installation?
>>
>> Commercial ASN.1 encoder/decoders are available which do not carry
>run-time licenses.  Of
>> course the ASN.1 compiler costs money (often per seat or per floating
>license).  Therefore,
>> your costs can be all fixed costs with no variable costs as regards ASN.1
>encoding/decoding.
>> Support is also available, plus consulting, training, etc.  Because
>knowledge of ASN.1 is not
>> necessarily as widespread as text parsing tools, it is likely that
>internal training costs will
>> be higher, or costs spent in wages to developers will be higher.
>>
>> Text parsers based on bison/flex (yacc/lex) can be used for free (well
>relatively, check the
>> GNU license about distributing source code for the parser generators with
>the run-time).  Of
>> course there is little support available, however, many programmers in
the
>industry are
>> familiar with these tools.  ABNF descriptions are easily translated to
>bison/flex and efficient
>> parsers will result.  Reference implementations using these almost free
>tools can be used as a
>> starting point.  Other tools exist.  Development costs are likely to be
>lower than the ASN.1
>> case, however, support costs are likely to be higher if it is provided
>internally (rather than
>> via the vendor of the compiler in the ASN.1 case).  Again, there are no
>run-time fees
>> associated with these tools.  There are some distribution costs
>(distributing source).
>>
>> So in both cases most of your costs (for parsers) are fixed, variable
>costs associated with
>> either approach is negligible.  (Isn't software wunderful?)
>>
>> > Cost may be a trivial issue for many oprganizations but there are about

>a hundred (maybe
>> > more) odd organizations trying to make MEGACO Gateways for which cost
of
>the end-product
>> > really matters.
>>
>> Of course cost matters; however, your analysis should compare the
>estimated fixed costs of the
>> approaches spread across the target unit volume with other costs to
>determine a break-even
>> point and price point.  I truly believe that hardware costs and the costs
>of Stage I
>> manufacturing of hardware (or purchase of hardware) during startup will
>represent the more
>> significant cost.  No significant cost reductions are likely to result
>from either approach
>> over the other.
>>
>> > I will appreciate if somebody could throw some light on this issue.
>>
>> This is my two bits.  My opinions are my own and I take no responsibility
>in them.
>>
>> > [snip]
>>
>> --
>> Brian F. G. Bidulock
>> Associate Director - New Products
>> Inet Technologies Inc.
>>