Subject: [dispatch] SIP-CLF: text versus binary

From: Eric Burger <[email-masked]>
Date: Fri, 1 May 2009 09:48:13 -0400

I would humbly offer that the number of iterations it took for Theo  
(super awesome coder), Adam (truly awesome coder), and Vijay (above  
average coder) to get a half decent binary implementation of a CLF  
writer and reader highlights the argument for a text-based LOG file.   
Imagine what an average coder would do.

Binary file formats are not easy. SIP-CLF is trivial and it is not easy.

Questions for people to consider:

Why isn't SIP in a binary format? It would be much easier to generate  
and parse the message, and the message would be smaller.

Why is H.248 a text protocol in the wild, even though the binary  
format had tons of intellectual effort poured into it?

Why are SNMP MIBs a black art, years after their introduction?

---

From: Simon Perreault <[email-masked]>
Date: Fri, 01 May 2009 10:00:42 -0400

Eric Burger wrote, on 01/05/09 09:48 AM:
> Why is H.248 a text protocol in the wild, even though the binary format
> had tons of intellectual effort poured into it?
> 

This is exactly what I meant by "speed is not an issue".

- File size is similar.
- Output speed is similar.
- Input speed is inconclusive (I guess it would tend toward similar with more
effort.)

The real issue is: ease of use, flexibility, "greppability", etc. This all
points toward the text format.

By the way, there is a wide body of knowledge with HTTP log formats, which are
not standardized but very many people use the Apache format. This means there is
code, tools, libraries, etc. that can be reused. This is a solved problem.
Experience has shown that text log formats work.

Simon (forgotten coder)
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Bob Penfield <[email-masked]>
Date: Fri, 1 May 2009 10:12:09 -0400

We could eliminate the implementation issues by including the code in the RFC.

I personally prefer the binary format.

Cheers,
(-:bob

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 May 2009 10:58:52 -0400

Eric,

I have pondered the questions you raise for many years, and I still 
don't know. I *think* it is mostly a matter of easing the learning curve 
to get started on something. Once you have worked on it for awhile, you 
have a set of tools, and whether the underlying representation is text 
or binary is the least of concerns. But for those first few weeks before 
you have figured out what tools you need and obtained or built them, a 
text rep is very helpful.

An interesting case study is print formats. A *long* time ago Xerox had 
a binary print representation, called InterPress. It was proprietary and 
not very approachable. Some people left Xerox, formed Adobe, and 
produced a text print format (PostScript), which for some reason was 
vastly more popular. Does it matter that postscript is text rather than 
binary? Probably not in practice, but somehow it did matter. (Or course 
now ps has been pretty much subsumed into pdf, which I think is a binary 
format.)

So, for reasons I still don't fully fathom, I agree with you that its 
probably important to have a text rep as the primary one, even if it is 
suboptimal, and if there is also a binary format people probably won't 
implement it.

	Thanks,
	Paul

Eric Burger wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Adam Roach <[email-masked]>
Date: Fri, 01 May 2009 10:23:20 -0500

> writer and reader highlights the argument for a text-based LOG file.

Vijay's initial implementation was pretty much spot-on, with one easily 
fixed exception. Improvements past that point were pretty much 
incremental, minor, and inconsequential in the grand order of things 
(except for Theo's last change, which is really just Theo working some 
deep voodoo magic that would apply equally to text and binary).

In either case, the speed of processing one versus the other stands at 
5x to 10x by any reasonable metric.

> Imagine what an average coder would do.

Any coder sufficiently competent to get a SIP parser even halfway right 
should be able to code this in their sleep.

 > We could eliminate the implementation issues by including the code in 

I like that idea. I'll adapt my perl script to a library and add it as 
an appendix to the next version of the binary CLF document (presuming 
there's any reason to produce a "next version").

/a

---

From: Tom Taylor <[email-masked]>
Date: Fri, 01 May 2009 15:15:23 -0400

Just for fun, I'll remind you all that we tried to decide the H.248 text vs. 
binary question by the flip of a coin. The coin came up "text" while the H.248 
rapporteur sat there with his jaw touching the floor, but then Pete Cordell came 
up with the idea of text-encoded ASN.1 and that kept the issue alive. It turned 
out the real reason the binary wouldn't die was that some people wanted to carry 
it in ISUP (BICC, actually).

Tom Taylor

Eric Burger wrote:
...

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 01 May 2009 15:26:22 -0500

Adam Roach wrote:
 > Vijay's initial implementation was pretty much spot-on, with one
 > easily fixed exception.

Adam: Thanks, and once again, I take the blame for not paying
enough attention to the binary CLF write function (but that is
the whole reason why I published the source as well -- just in
case I did not account for something egregious.)

 > 5x to 10x by any reasonable metric.

To be sure, you are saying that a perl script finding a certain
record in an ASCII CLF file is about 5x to 10x times slower
than a C program or perl script finding the same record in a
binary CLF file.  If so, yes, that is so.  The writes are
about even, with binary writes taking up a bit less time.

There are other technical discussions that I will like to
continue with you on the merits and demerits of ASCII vs.
binary, but will wait for a short while until we decide to
see how the SIP CLF work progresses in dispatch (hopefully we
can conduct those on a separate technical discussion list.)

Ciao,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Christian Groves <[email-masked]>
Date: Mon, 04 May 2009 10:23:01 +1000

The reason was not to carry it in ISUP or the BICC protocol (I'm not 
aware of any spec doing this). Companies wanted to use it in gateways 
where ISUP, BICC and H.323 were the call control protocols. All these 
were binary. That's why ITU-T and 3GPP adopted binary for those 
applications. However as H.248/Megaco evolved many applications were 
more closely tied to the work of the IETF and the usage has tended to be 
toward text implementations. Both the text and binary had tons of 
intellectual effort poured into them.
The text version is certainly easier for humans to read but slightly 
more problematic because a human must understand the grammar.
In terms of the technical performance like the tests here have shown the 
results are very dependent who has done the encoding.

My advice would be to pick one (if you use the coin method make sure it 
doesn't roll under a chair :-) ) and then document an optimised encode / 
decode code as part of the spec to try to minimise performance variability.

Good luck,
 Christian

PS: And no I wasn't rapporteur at the time.

Tom Taylor wrote:
> Just for fun, I'll remind you all that we tried to decide the H.248 
> text vs. binary question by the flip of a coin. The coin came up 
> "text" while the H.248 rapporteur sat there with his jaw touching the 
> floor, but then Pete Cordell came up with the idea of text-encoded 
> ASN.1 and that kept the issue alive. It turned out the real reason the 
> binary wouldn't die was that some people wanted to carry it in ISUP 
> (BICC, actually).
>
> Tom Taylor
>
> Eric Burger wrote:
> ...
>>