Subject: [bmwg] WGLC comments for draft-bmwg-ipflow-meth

From: Brian Trammell <[email-masked]>
Date: Mon, 28 Mar 2011 16:44:01 +0200

Greetings, all,

These are last-call comments for draft-bmwg-ipflow-meth-00. 

General comment: The document appears to be focused directly on a subset of flow monitoring devices (those running on packet forwarding devices), focused on answering a question only applicable to those devices ("What is the cost of enabling the IP Flow monitoring and export to a collector?") and indeed specifically ignores the possibility of flow export from devices not also forwarding packets ("Since Flow monitoring will in most cases run on network devices forwarding packets..."). There is a statement in section 3.2 that "These devices can be network packet forwarding devices or appliances which analyse the traffic but do not forward traffic (probes, sniffers, replicators)". However, the rest of section 3 (especially section 3.1, Figure 1 in section 3.3, and section 3.4.2 in its entirety) clearly makes an assumption that the measurement device is forwarding packets.

At the least, I would suggest changing the model in figure 1 and the definition in section 3.1 to make the forwarding plane optional, and to ensure that language about throughput is clear that forwarding is optional. On the other hand, if the true intent of this draft is only to apply to forwarding devices, a title change to "Benchmarking methodology for IP flow measurement on packet forwarding devices" and associated changes to the frontmatter would address this comment. 

The statement "The Flow monitoring performance metric is not applicable to the Collector since it does not implement the RFC5470 architecture" is incorrect. 5470 covers collecting processes as well, although in not as much detail as metering and exporting processes. Suggest simply stating that CP performance is out of scope for the the draft; that should in itself be sufficient.

Section 4.4 should note that in certain cases (IPFIX export as in 5101 via SCTP-PR with reliable flow export, or via TCP) the collector performance may impact the exporter performance due to head-of-line blocking, and potentially exclude these. Similarly, the requirement in Section 4.4 that "The Collector MUST be capable to capture at the full rate the export packets are sent from the DUT without losing any of them" ignores that, when using unreliable export, buffers on the exporter may also be responsible for loss. 

A couple of questions:

Also in section 4.4, the reasoning behind the following is unclear: "The Collector SHOULD support Ethernet type of interface to connect to the DUT but any media which allows data capturing and analysis can be used." Is this an arbitrary decision (reasonable, IMO -- I don't think we've ever tested IPFIX over anything not-Ethernet)

In section 4.7, I presume that the frame sizes refer to the generated test traffic, not to the exported traffic. Should the export MTU on the EP also be varied for testing? (If this is out of scope, fine.)

Best regards,

Brian

---

From: "Jan Novak (janovak)" <[email-masked]>
Date: Mon, 28 Mar 2011 17:48:43 +0200

Hi Brian,

Thanks a lot for your review - will address your comments in the next
version.

> Is this an arbitrary decision

Ethernet seems to be always assumed media and if nothing else then at
least that
should be supported. The rest was just to say it does not have to be so
- we used to have Netflow collectors sitting on ATM interfaces. Feel
free though to
suggest some text which would clarify that ...

> (If this is out of scope, fine.) 

It's actually a good point, thanks - the smaller the export packet the
more packaging the DUT
must do and it can affect significantly the performance as well - a well
known
effect from BGP update packaging ... (e.g. will add some text on it).

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
Brian Trammell
Sent: 28 March 2011 15:44
To: [email-masked]
Subject: [bmwg] WGLC comments for draft-bmwg-ipflow-meth

Greetings, all,

General comment: The document appears to be focused directly on a subset
of flow monitoring devices (those running on packet forwarding devices),
focused on answering a question only applicable to those devices ("What
is the cost of enabling the IP Flow monitoring and export to a
collector?") and indeed specifically ignores the possibility of flow
export from devices not also forwarding packets ("Since Flow monitoring
will in most cases run on network devices forwarding packets..."). There
is a statement in section 3.2 that "These devices can be network packet
forwarding devices or appliances which analyse the traffic but do not
forward traffic (probes, sniffers, replicators)". However, the rest of
section 3 (especially section 3.1, Figure 1 in section 3.3, and section
3.4.2 in its entirety) clearly makes an assumption that the measurement
device is forwarding packets.

At the least, I would suggest changing the model in figure 1 and the
definition in section 3.1 to make the forwarding plane optional, and to
ensure that language about throughput is clear that forwarding is
optional. On the other hand, if the true intent of this draft is only to
apply to forwarding devices, a title change to "Benchmarking methodology
for IP flow measurement on packet forwarding devices" and associated
changes to the frontmatter would address this comment. 

The statement "The Flow monitoring performance metric is not applicable
to the Collector since it does not implement the RFC5470 architecture"
is incorrect. 5470 covers collecting processes as well, although in not
as much detail as metering and exporting processes. Suggest simply
stating that CP performance is out of scope for the the draft; that
should in itself be sufficient.

Section 4.4 should note that in certain cases (IPFIX export as in 5101
via SCTP-PR with reliable flow export, or via TCP) the collector
performance may impact the exporter performance due to head-of-line
blocking, and potentially exclude these. Similarly, the requirement in
Section 4.4 that "The Collector MUST be capable to capture at the full
rate the export packets are sent from the DUT without losing any of
them" ignores that, when using unreliable export, buffers on the
exporter may also be responsible for loss. 

A couple of questions:

Also in section 4.4, the reasoning behind the following is unclear: "The
Collector SHOULD support Ethernet type of interface to connect to the
DUT but any media which allows data capturing and analysis can be used."
Is this an arbitrary decision (reasonable, IMO -- I don't think we've
ever tested IPFIX over anything not-Ethernet)

In section 4.7, I presume that the frame sizes refer to the generated
test traffic, not to the exported traffic. Should the export MTU on the
EP also be varied for testing? (If this is out of scope, fine.)

Best regards,

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

---

From: Brian Trammell <[email-masked]>
Date: Tue, 29 Mar 2011 09:56:29 +0200

Hi, Jan, all,

Amending my WGLC comments as at the mike this morning:

An IPFIX architecture Metering Process (MP) on a non-forwarding (measurement-only) device can essentially be modeled as in section 3.3, but with no output interface (or rather, as a forwarding device with no routes). As such, IPv4/IPv6 packet rate would be 0, packet rate measurements would be irrelevant, and flow measurement throughput then becomes the only metric of interest. 

I'd propose that this would be a cleaner way to take this draft and make it applicable to both the forwarding device and dedicated measurement device cases -- a short note about this model at the relevant point in section 3 would probably do it.

Best regards,

Brian