Re: comments on version 2 of protocol draft

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

It is not how big and complex the messages are. Having faster communication
channels does reduce latency, but doesn't reduce the costs of buffers
and computational costs. Remember, a manager supports multiple managed
systems. You don't want to significantly reduce the number of systems
that a manager can support. It's the total costs, not just the
communication cost between a manager and one managed system.
So, it's not just the bandwidth. Also, as Wes points out, there
are fixed costs with developing the software and on going costs
with running the software. (And ongoing costs maintaining and 
extending the software.) The hard part is making choices so that
the results are acceptable even when there is not "perfect
knowledge" on the costs and usage! That is, the ideal approach
would be self stabilizing. 

At 10:01 PM 3/2/2004 -0800, Wes Hardaker wrote:
>>>>>> 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.
>
>-- 
Regards,
/david t. perkins 


--
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/>