In message <199608310000.TAA17929@uh.msc.edu>, Tim Salo writes:
Actually, it would be nice if this "portable test kit" were actually an optional board for a router. You could, for example, stick the "portable test kit" board in a router and then test at will.
Any of the ISPs losing packets like crazy need only look at the stats on their routers. We saw some creative lying at the last NANOG. I heard the statement "we have no loss on our links". No kidding. Now look on the routers. That is where congestion loss occurs and that is where loss due tolimitations in the router implementation will be recorded. The providers that are losing a lot of poackets can very easily look at these stats but they aren't about to put them on a viewgraph and bring them to NANOG.
We also tried to explain to our ATM tester vendors that we wanted ttcp implemented in the ATM tester. Some understood, some didn't...
-tjs
This is an interesting problem and actually close to solvable at the IP level. I'm sure you are familiar with PPP LQM. Take out the PPP part and keep the LQM packet format and local storage. Keep one LQM struct per ARP entry on a bcast or nbma interface (such as an ATM NAP). Count packets used by each ARP entry and update SNMP and the LQM entry as you would in PPP LQM. Occasionally (once a second is fine) send an LQM packet summarizing what has been sent. When you make two successive queries from the command interface one either side, you cat check the differences and get an exact (accurate to the packet) count of the packets sent during that period and the loss during that period. Then you just have to drive the network with whatever load you think appropriate. My understanding is that the ATM NAPs are not experiencing any level 2 loss at all so this is really not an issue for the NAPs. This clearly would be useful for ISPs using ATM or any switched service that doesn't absolutely guarentee no loss (ie: != VBR-V). Curtis