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

["Jan Novak (janovak)" <janovak at cisco.com>]

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

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

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

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.

> Section 3.4 on measurement procedure refers to "gradually increasing
> 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: bmwg-bounces at ietf.org [mailto:bmwg-bounces at ietf.org] On Behalf
Of
> David Newman
> Sent: 29 October 2009 16:27
> To: bmwg at ietf.org
> Subject: [bmwg] more comments on draft-novak-bmwg-ipflow-meth-04
> 
> 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
> 
> 
> 
> _______________________________________________
> bmwg mailing list
> bmwg at ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg