Subject: RE: sub-tree filtering proposals

From: "Michael Walton" <[email-masked]>
Date: Thu, 10 Jun 2004 09:09:06 +0200

Regarding code size of XPath: for interest and discussion's sake, I did a little footprint test using libxml2.

xpath.c seems to contain all the required processing, and is a fairly hefty source file at 324K.

Compiled and stripped it produces an object file of 88K. I tried gcc-i386 and gcc-ppc and both produce similar results.

Compressed (using mkcramfs for compressed ROM filesystem) it ends up at 36K. I haven't checked whether it incurs additional library requirements, etc. but I think it illustrates a point. 

YMMV :-)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Frank Strauß
Sent: Wednesday, June 09, 2004 10:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: sub-tree filtering proposals

On 09. Jun 2004, at 15:42, Juergen Schoenwaelder wrote:

> [...]
> First, I believe a subset of XPATH (not an adapted subset) is still 
> better
> than something homegrown.

I agree.

> (The most vocal members of the WG do not seem
> to buy full XPATH as a requirement.)

Maybe the reason is, that there are still not many operators and 
developers
of manager software raising their voice. (I'm just guessing.)

>  Personally, I believe that the
> operators using netconf will ask for full XPATH anyway, so the subset
> requirement will likely not be a real issue in practice.

However, a netconf standard should have the purpose to come to a common
sense on what agents support and what managers can rely on. If we have
reasons to assume that operators and others will ask for full XPath (and
I do think so, too) we should address this need *now* (and BTW not in a
subsequent revision as long as we did not even find rough consensus for
the initial revision).

> I think the general idea is that boxes announce whether they do 
> support full
> XPATH or just a reduced subset. I do not see that there is anything 
> wrong
> with this.

In general, I agree.

> The alternative, a home grow filter format which implementations are
> required to support, seems worse to me. Bottom line is that either
> (a) the netconf WG makes a decision to require XPATH full stop, or
> (b) the WG makes a decision to support XPATH and require a subset of 
> it, or
> (c) the WG makes a decision to support XPATH and to require another
>     home-grown filter format.
>
> Since (a) does not seem to be getting WG consensus, I believe (b) is 
> the
> best we can do.

First to say, my preference would be (a). If there are reasons against 
(a)
(I guess, I missed a discussion on this), I would also favor (b) over 
(c).

On 09. Jun 2004, at 18:22, Juergen Schoenwaelder wrote:

>> The advantages of the proposal above are:
>>   - subtree filtering is easy to implement on agents;
>>     only XML parser needed, not XML and Xpath parsers
>
> Come on, parsing Xpath expression is really not that complicated. I am
> really wondering on which basis you calculate how much you save on
> embedded boxes...

I would also like to see a clear reasoning, not just on the pure code
size. These aspects come to my mind:

- We should take into account that many XPath implementations exist.
   My expectation would be that deriving a subset implementation would
   need some time (not much, but more that just picking an existing
   full implementation) just to shrink the code size for a small
   percentage.
- An XPath subset would most probably *not* reduce CPU load compared
   to full XPath.
- Building a new XPath (subset) implementation from scratch could be
   required by some vendors' policies. A full implementation would fit
   in the idea of reusability, while a netconf subset would be limited
   netconf only.
- Same is true for a home-grown filtering mechanism.
- A less powerful filtering mechanism would cause more network traffic
   and thus increase network and CPU load, since managers would have
   to retrieve more data than required if the required filtering cannot
   be done on the agent side.

Furthermore, nowadays even the cheapest APs, switches and other devices
come with an HTTP server, SSH, SNMP, syslog, and much more stuff. 
Firmware
resides in relatively large, however cheap enough flash memory. The ease
of usability and manageability through such features often makes it an
attractive and successful product. This generally weighs more than the
costs to develop and build such features. At least, this is my 
impression.

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

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

---

From: Frank Strauß <[email-masked]>
Date: Thu, 10 Jun 2004 11:42:16 +0200

Michael Walton wrote:

> Compiled and stripped it produces an object file of 88K. I tried gcc-i386 and
> gcc-ppc and both produce similar results.
> 
> Compressed (using mkcramfs for compressed ROM filesystem) it ends up at 36K.
> I haven't checked whether it incurs additional library requirements, etc. but
> I think it illustrates a point. 

Thank you very much, Michael!

So the difference in (compressed) size compared to an XPath subset or another
limited home-grown filtering mechanism is probably less than 25kB. I don't see
the point in saving this amount of memory compared to all the disadvantages
(enumerated in my last message) that a non-(full)-Xpath solution would cause.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 10 Jun 2004 09:15:08 -0700

>Compressed (using mkcramfs for compressed ROM filesystem) it ends up at 36K. I haven't checked whether it incurs additional library requirements, etc. but I think it illustrates a point. 

The code size at runtime, on the runtime platform, is the first
interesting number.  The size of the compressed file on disk is
irrelevant.  You don't show the most interesting number, which
is the static and dynamic data memory usage during the processing 
of a <get-config> or <get> operation.  Memory is a precious resource 
on small embedded devices, which do networking as their primary task, 
not Xpath.  No customers are asking for Xpath on small devices -- 
there isn't enough config there to worry so much about retrieval filtering.
IMO, it is unacceptable to make Xpath mandatory because not all devices 
need it nor can support it without impacting manufacturing cost.

>Mike

Andy

---

From: Frank Strauß <[email-masked]>
Date: Thu, 10 Jun 2004 19:58:11 +0200

> of a <get-config> or <get> operation.  Memory is a precious resource

As far as I know, RAM is much cheaper than flash memory.

> not Xpath.  No customers are asking for Xpath on small devices --

Customers are asking for consistent specs without too many options,
since every options might have to be handled differently and cause
trouble.

> there isn't enough config there to worry so much about retrieval 

That *might* be true. The manager might not know in advance.

> need it nor can support it without impacting manufacturing cost.

In situations where resources are really that limited, XML is the wrong
choice anyway. My expectation would be that devices that implement 
netconf
will not have such limited resources.

Another questions comes to my mind:

If limited devices would receive a request with an unsupported XPath
predicate, would it (a) return an error message or would it (b) return
a result document that might be larger than the document returned by a
full XPath implementation (e.g., by just stripping any occurance of
"[...]")?

I just started thinking about (b). And at first glance, it could
probably be a reasonable compromise: The client would not have to care
about the agent's #xpath capability and the fact that the returned
document contains unrequested nodes would probably not cause any
problems. The response should probably signal somehow that the request
contained an unsupported filtering expression.

What do you think?