Re: [ippm] I-D Action:draft-ietf-ippm-metrictest-00.txt

[Jerome Benoit <[e-mail]>]

Le Tue, 06 Jul 2010 08:34:21 -0400,
Al Morton <[e-mail]> a écrit :


> 
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrictest-00.txt
> >
> >Do you plan do add inaccuracy introduced by runtime on each
> >implementation ?
> 
> Sorry, but it's not clear to me where your comment applies.

I'm not a math guru but I wanted to know if the proposed draft will
take in account inaccuracy on timestamping that come only from the
runtime. For example, we have some Proof of Concept code (probecraft :
http://github.com/lucasdicioccio/probecraft ) that is able to send most
of the known active probes, but we have chosen on the implementation
side to rely only on lipcap and its timestamping capability on packets :
the wire-time is what lipcap give us. It's a design choice. If the
kernel has a lot of packets to treat, the desired time series for
some sort of probe will not be followed as requested. If lipcap is able
to use some kernel facilities to bypass buffering or routing table,
we can minimize runtime inaccuracy.  

There is other bias that can be introduced on the probing src host that
can invalid the probe (ARP cache, etc.). The probing src host can be
very noisy ... 

> Each of the metric RFCs cover error sources and error reporting,
> so (if I understand your question) this is one of the areas to
> check and see if implementing developers understood the requirements.

Oki. 
 
> >Do you plan to you plan to test implementation that
> >will not follow IETF OWAMP (or TWAMP) RFC but will largely inspired by
> >them (NAT friendliness of theses RFC make them difficult to follow
> >when you want to send probes from the network edge et behind a CPE) ?
> Yes, this draft starts from the premise that measurement results from
> different implementations will be compared. Neither OWAMP or TWAMP
> are required.

Great. 

Thks. 

-- 
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D