Subject: Re: XML experience/learning in FACT/TIPC implementation

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 28 Mar 2003 11:07:51 -0800

Hi Jon, Rachid

Your current XML experiments have only tried Add Routes, which is probably
one of the simplest structures to encapsulate and even with that seems like
the performance was an order of magnitude less than simple TLV approach. It
would be interesting to see the performance for more complex structures
which would be part of the FE Model such as DiffServ structures.

Thanks
Hormuzd
-----Original Message-----
From: Rachid Nait Takourout (LMC) [mailto:[email-masked]]

Sent: Friday, March 28, 2003 9:55 AM
To: [email-masked]
Subject: Re: [FORCES] XML experience/learning in FACT/TIPC implementation

Hi,

        As Jon said, our XML experience was a test in order to prove the
possibilities of this choice. In fact, the performances for each add-route
were lower with XML, but the XML parser (it is Expat) was not created
specificly for this type of application.  So, if we would design an advanced
router, the use of different types of NP (Intel, EzChip...) poses the
problem of the management of the heterogeneity. XML could provide a generic
way to express command that could be independant of APIs like the NPF API.
It could be interesting to have a XML based FE Model and protocol which are
coherent.

Rachid Nait Takourout

-----Message d'origine-----
De : Alan DeKok [mailto:[email-masked]]
Envoyé : Friday, March 28, 2003 12:30 PM
À : [email-masked]
Objet : Re: XML experience/learning in FACT/TIPC implementation

Jon Maloy wrote:
>
> Hi,
> Our experiences with XMLas representation language are generally
> very positive. XML is well fit to express the commands and queries
> needed in the protocol.

  There was also an 'xmlconf' or 'netconf' BOF, which met at IETF-56 on
Monday.  If we decide to use XML as a ForCES protocol, it would seem
that there may be significant overlap between the two groups.

> Our main concern from the beginning was performance, but our
> experiments indicate that this is not  a big problem.

  Assuming that the machines involved are powerful, and have sufficient
memory.  As Moore's law shows, this is probably a reasonable assumption,
given the timescales involved with creating a new protocol in a working
group.

> With XML each add-route item is around 10 times larger than the
> corresponding items in the FLEX protocol, and we have indications
> that  this will cause the the whole transfer/parsing process to be an
> order of magnitude slower than with 'native' FLEX or FACT.

  The question is then whether this slowdown is significant.  If the
total bandwidth devoted to ForCES is minimal, then increasing it by a
factor of 10 is probably acceptable.

> So the question we must answer is the following: Is a performance
> degradation of ~10 times worth the price, given the extra flexibility
> that XML provides over FLEX/FACT?

  And given the extra cost of implementing more complicated parsers.

  For now, it looks expensive to me, but not outlandish.

  Alan DeKok.

---

From: Alex Audu <[email-masked]>
Date: Fri, 28 Mar 2003 14:16:12 -0600

Also, don't forget other applications that may need a lot bandwidth between CEs
and FEs,
for example, traffic measurement. Typically you'd like your observers in the FEs
to forward
collected flow records to the Export process in the CE for aggregation and
onward export to
an external collector. I don't know what effect the XML model will have on this,
but  you need
as much bandwidth as you can get,..and you don't want to do anything that may
impact this.

Regards,
Alex.

---

From: Jon Maloy <[email-masked]>
Date: Fri, 28 Mar 2003 18:52:29 -0500

I think the conclusion should be that we need to continue and widen the
scope of our prototyping.
We must also do some theoretical calculation on hwo much bandwidth 
the use of XML will actually require, taking into account its ratio of
of the total traffic load.
If TIPC is chosen as bearer one should also consider that it is capable
of 
using 4 Ethernets in full load-sharing. With 10 Gbit Ethernet interfaces
and switches there should be some potential....

Do anybody have an overview over the required frequency and distribution
of 
different types  of commands/queries, both relative to each other an as
a part 
of the total?

/Jon

Alex Audu wrote:

Also, don't forget other applications that may need a lot bandwidth
between CEs

and FEs,

for example, traffic measurement. Typically you'd like your observers in
the FEs

to forward

collected flow records to the Export process in the CE for aggregation
and

onward export to

an external collector. I don't know what effect the XML model will have
on this,

but  you need

as much bandwidth as you can get,..and you don't want to do anything
that may

impact this.

Regards,

Alex.

  

Hi Jon, Rachid

Your current XML experiments have only tried Add Routes, which is
probably

one of the simplest structures to encapsulate and even with that seems
like

the performance was an order of magnitude less than simple TLV approach.
It

Thanks

Hormuzd

-----Original Message-----

From: Rachid Nait Takourout (LMC) [
mailto:[email-masked]
<mailto:[email-masked]> ]

To:  [email-masked] <mailto:[email-masked]> 

Subject: Re: [FORCES] XML experience/learning in FACT/TIPC
implementation

Hi,

possibilities of this choice. In fact, the performances for each
add-route

specificly for this type of application.  So, if we would design an
advanced

problem of the management of the heterogeneity. XML could provide a
generic

way to express command that could be independant of APIs like the NPF
API.

It could be interesting to have a XML based FE Model and protocol which
are

coherent.

Rachid Nait Takourout

-----Message d'origine-----

De : Alan DeKok [ mailto:[email-masked] <mailto:[email-masked]>
]

À :  [email-masked] <mailto:[email-masked]> 

Jon Maloy wrote:

Hi,

needed in the protocol.

    

group.

    

  Alan DeKok

.