With deployment of the vBNS and NAPs, the situation grows even more disturbing. The National Information Infrastructure continues to drive funding into
hardware, pipes, and multimedia-capable tools, with very little attention to any kind of underlying infrastructural sanity checks.
And until now, the primary obstacles to accessing traffic data in order to investigate such models has been political, legal (privacy), logistic, or proprietary.
With the transition to ATM and high speed switches, it will no longer even be technically feasible to access IP layer data in order to do traffic flow profiling, certainly not at switches within commercial ATM clouds. The NAPs were chartered as layer 2 entities, that is, to provide a service at the link layer without regard for higher layers. Because most of the NSFNET statistics reflected information at and above layer 3 (i.e., the IP layer), the NAPs cannot use the NSFNET statistics collection architecture  as a model upon which to base their own operational collection. Many newer layer 2 switches, e.g., DEC gigaswitch, ATM switches, have little if any capability for performing layer 3 statistics collection, or even looking at traffic in the manner allowed on a broadcast medium (e.g., FDDI, Ethernet), where a dedicated machine can collect statistics without interfering with switching. Statistics collection functionality in newer switches takes resources directly away from forwarding of frames/cells, driving customers toward switches from competing vendors who sacrifice such functionality in exchange for speed.
cost-benefit tradeoff: (minimalist approach) collect what is necessary at least cost to switching performance