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


On the following....

At 03:54 PM 12/5/2001 -0800, Subrata Goswami wrote:
>Questions on the draft "Efficient Transfer of Bulk SNMP Data".
>1. Why is an TLV type encoding required ? Is it not possible to 
>   simple ASCII encoding (is done HTML).
TLV is better than just "simple ASCII".

>2. How much overhead does BER added compared to simple ASCII ?
BER encoding in most cases is more efficient to encode than
ASCII, and in many cases it is smaller in size. Remember, that
most bulk data is statistics (numbers) and status (typically
a small number or a few bits).

>3. I am trying to understand what the following section imply.  To the
>   best of my knowledge most devices now a days have HTTP servers embedded
>   for device management. So no extra overhead would be there as the device
>   understands both HTTP and HTML.
It is not the case that most devices have embedded WEB servers. Using
a WEB server takes up much more resources than SNMP or an FTP client,
or FTP server.

>   "Other non-SNMP alternatives for bulk transfer include using MIME or 
>   XML Document Type Definition (DFD) to encode the MIB data. The data 
>   can then be transferred via the well-known HTTP protocol since it is 
>   well suited for bulk transfer of MIME-encapsulated data. However, 
>   since HTTP is primarily intended for transferring World Wide Web 
>   data, it has many features and options that are not required for 
>   management data. However, a compliant implementation will 
>   nevertheless have to implement those features thereby increasing the 
>   size and complexity of the SNMP implementations without additional 
>   benefit. In addition, future evolution of HTTP may add features or 
>   requirements that make it unsuitable for transferring MIB data."
Here is a description of the problem....
* In "small" network devices that are used in homes, small offices,
  and small enterprises, there is not much data, so bulking it
  is not a problem. These are typically the class of devices
  that have an embedded WEB server. These devices are not
  typically CPU max'ed out.
* For devices that are used in medium sized (and larger) enterprise 
  networks, and ISP networks, there is much data, and bulking is
  important. For these devices, they typically are not managed with
  an embedded WEB server. For lower-end devices (and older devices),
  they are typically CPU max-out when loaded (and, thus, have a
  lot of data). For higher end devices, they can have massive
  quantities of data. 
* the manager side issues are easily resolved. If you run out of
  CPU cycles, then it is easy (and not too costly) to upgrade the
  manager station (or even distribute the work). Likewise, adding
  memory, disks, network interfaces is easy and inexpensive 
  compared to "upgrading" a network device. With a network
  device, you have very limited choices (if any) from the vendor
  in increasing the processing power or adding memory, or

So, my conclusion is that ASCII HTML encoding and using HTTP seem
to be undesirable choices from the device side of things compared
to, say, an efficient SNMP encoding or using FTP. 


/david t. perkins