Subject: [bmwg] Feedback on draft-novak-bmwg-ipflow-meth-01.txt

From: "Jan Novak (janovak)" <[email-masked]>
Date: Wed, 19 Nov 2008 11:57:28 +0100

Hi Benoit et al,

Thanks a lot for the discussion on the subject - the input certainly
makes the document much better.

I would want to ask folks to send their feedback to the list as well
- it makes it easier to implement it later.

I answered the most important point from your review below:

>Isn't it: what will be the CPU impact
>Isn't it: what will be the impact on the forwarding performance?

It meant to say what they will be with Flow monitoring enabled

>I don't know what you mean by application

I thought about it in terms of OSI model - which is indeed not clear
here -
the thing which does Flow Monitoring inside of the UUT is an application
layer entity

- Why is following important?
	   This document covers IP (both IPv4 and IPv6) flows or MPLS
	   encapsulated IP flows, any other protocols or traffic types
are out
	   of the scope.

I wanted to clearly specify what is the scope of the document based
on received comments about probes, collectors etc. It is true that
on one hand it may be unnecessarily restricts it on the other hand we
have
no experience with anything other.

>Doesn't depend on the expiration timeout?

I wouldn't think so - the conditions of each measurement are (or need to
be)  set up in such a way that you can achieve some reasonable time
interval with stable conditions to allow you to measure some CPU average
over reasonably long period. If the expiration timeout implementation
does not allow it it is simply impossible to measure anything (or
just do the things which need the flows expired quick)

> I don't understand why wrote "
	DUT needs to have very basic configuration just allowing IP
packet
	   forwarding without any use of dynamic IP routing protocols."?
> You're afraid of the CPU impact?

No, its just that in a physics experiment if you want to measure
something
you want to have as clean environment as possible so you can rule out
any other influencing circumstances on the measurement result. Here the
idea
was I want to measure this so lets have anything else out of the UUT -
its
true I later noticed that the Network Device BM RFC does the opposite -
load
the UUT with everything you have on the live device and then measure Non
Drop
Rate. Not sure what to do here (if you let people have OSPF and each
OSPF
behaves differently in terms of periodical processes and you measure
Flow
Monitoring on top of that which behaves same for both but the results
will
be different - so what have you measured ??)

>Am I right to say that you speak about a distributed router
architecture with line card?
>You might want to give a clear example.
>You might also explain that different LCs have different Observation
Domain [RFC5101] 
>What is your advice wrt to distributed architecture: 
	- test all possibilties?
	- test a single one? Then which one?

Yes, I wanted to somehow abstract from Cisco terminology but could not
find something
within IETF which would define those and did not want to spend time on
defining
those.
The aim was to bring to the attention that in the distributed case it is
implementation
specific who does what (like export from LC or RP etc) and that the CPU
usage
needs to be considered and measured on all CPU the system has. The
amount of
possible combinations one wants to verify would be then the liberty of
the 
tester :-) - he just needs to be aware of the problem

>Why do you assume an Ethernet interface? Is this a requirement?
>Do we want to test interface types? please justify.

It is relics from RFC2544 or RFC2285 - it goes down and specifies all
possible L2 frame formats (but yes just Ethernet ones since it is LAN
oriented). I just thought I need to do the same and did not realise I
restrict
it to the Ethernets by not specifying all the other WAN formats which
would
be quite tedious - so yes it needs to be somehow resolved without the
LAN frame
formats ...

>You assume a number of flow records equals to 90% of the cache size.
>So the cache size SHOULD be written down. 
>Or it doesn't matter? I mean: I update one flow every 1/10 sec, or 10
flows every 1 sec. Will it produce the same result?

Well you don't know in advance - only the first metric 5.2 will tell you
if it matters of not. I must say I anticipated here the Cisco behaviour
where the cache size if it is 100 000 or 1 000 000 entries does not
matter
- e.g. you don't spend any CPU on those if there are no changes to the
cache.
If so then when doing 5.3 you already know it does not matter and can
concentrate only on the packet rates.
So yes, I need to think about it and make it work for the case when
there
is non-zero CPU usage to maintain 100k or 1000k entries - how do we
execute
and report the measurement for 5.3. 

>Sender Traffic Definition:
>Define n traffic streams while incrementing the packet rate.

>Why is it important in the flow expiration rate, section 5.4

We discussed this already - it needs better wording to make the meaning
clear.

Thanks a lot, Jan

The climate of Edinburgh is such that the weak
succumb young .... and the strong envy them.

                                 Dr. Johnson 
_______________________________________________
bmwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bmwg