[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on version 2 of protocol draft



>>>>> On Tue, 2 Mar 2004 21:04:36 -0500, Bobby Krupczak <rdk@krupczak.org> said:

Bobby> Bandwidth is virtually free these days.  (I know, I know about dialup
Bobby> cases . . . . but text will compress.)

Bandwidth is not free in all environments.  I agree absolutely that if
netconf is used to configure a near-by router over a gig+ backbone,
who cares what it takes bandwidth wise.  I do care when I'm
configuring a very distributed network over small pipes, or pipes that
frequently drop or mangle things (wireless environments, through
satelites, to slow remote isolated places).  You may not still deal in
environments like that, but I and others do.

Bobby> I contrast that with the days in which BER was developed.
Bobby> Doing *all* that work to save a few lousy bytes of transmission
Bobby> might have been applicable in the dreaded X.25 days but its
Bobby> hardly worth the programming hassle/nightmare of coding BER
Bobby> (yuck!).

I'm not necessarily saying BER is better at being nice to encode.
Heck, I'd prefer a straight binary 8 byte copy of a integer value than
to transmit and parse "<value>18446744073709551616</value>".

(Even if you do go to a SNMP stack, for example, using BER...  When
was the last time you actually touched the BER parts of the stack.
Probably not in a long long time because they haven't needed to be
touched once they were complete.  XML will be the same.  Once you get
that integer parser down (regardless of whether you bought the tools
or rolled your own), the above is merely an API away from parsing it
regardless of whether its BER or XML).  

What matters to me is the speed at which you can parse it and the
bandwidth it takes to get there.  Yes, text compresses well.  It won't
compress better than a binary encoding will (not that I'm arguing for
using one...).  It will be larger (even when compressed) and take
longer to parse when you include values that could have been left out
(defaults).  Adding in more data to manipulate will make a difference.
I sure wish I had gig-interfaces running on fast boxes between here
and everywhere I need to work with, but I don't.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>