Subject: [bmwg] more comments on draft-novak-bmwg-ipflow-meth-04

From: David Newman <[email-masked]>
Date: Thu, 29 Oct 2009 09:26:48 -0700

A general comment and two nits on draft-novak-bmwg-ipflow-meth-04. Sorry
for getting to this so late.

The general comment:

The ID uses several metrics with time as a component (e.g., several
measures of flow timeout and cache overflow flow expiration in section
4.8), but does not specify goalposts for when these measurements begin
and end.

It would be highly desirable for all tools implementing these benchmarks
to measure in exactly the same way. RFC 1242 defines LIFO and FIFO
goalposts for latency measurement of store-and-forward and
bit-forwarding devices respectively; would similar goalposts be useful here?

I understand this is a packet-level question. But even in a flow-level
context, it would be useful to agree on starting and stopping points.

The two nits:

Section 2.2.3 (like RFC 5470) mentions "long-running flows" without
defining what interval constitutes "long". Consensus on some threshold
value would be useful (and perhaps necessary) to anyone implementing
tools to benchmark flow monitoring.

Section 3.4 on measurement procedure refers to "gradually increasing
traffic rates until losses are seen as fully specified by [RFC2544]".
RFC 2544 doesn't actually specify the use of the boiling-frog algorithm;
in fact, the only thing 2544 says about finding the throughput rate is
to use a binary search (section 24). It doesn't rule out the use of a
boiling-frog algorithm (also called a "step search" in polite company)
but it doesn't specify its use either.

Perhaps this could be reworded with the more generic form of "using a
search algorithm to determine the maximum rate at which none of the
offered frames are dropped by the DUT/SUT as described in [RFC1242] and
[RFC2544]."

dn

---

From: "Jan Novak (janovak)" <[email-masked]>
Date: Thu, 29 Oct 2009 19:37:06 +0100

> for getting to this so late.

Its great, thanks a lot - always better than never :-).

> bit-forwarding devices respectively; would similar goalposts be useful

I tried to define them in 5.1.3 and 5.2.3 but appreciate they
are not that accurate as the RFC1242 ones - will see to that.

> traffic rates until losses are seen as fully specified by [RFC2544]".

Here I thought section 26.1 of 2544 has enough on it but
again will do some more reading or just use what you suggest.

Thanks for your comments, Jan

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

                                 Dr. Johnson  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> David Newman
> Sent: 29 October 2009 16:27
> To: [email-masked]
> Subject: [bmwg] more comments on draft-novak-bmwg-ipflow-meth-04
> 
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg