Agenda for next NANOG
curtis at ans.net
Sat Aug 31 03:43:36 UTC 1996
In message <199608310000.TAA17929 at 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...
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
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).
More information about the NANOG