bcast LQM

> From: Curtis Villamizar <curtis@ans.net>
> LQM on non-PPP links sure would be great. A number of times I've
> suggested we consider LQM on bcast, with a set of LQM parameters per
> ARP entry. This way one end sends a LQM packet that serves as a time
> marker, counts packets, then includes the count in the next LQM time
> marker. The receiver needs only count packets between LQM packets and
> compare the local count against the count sent by the other end. This
> is an enormously oversimplified summary of LQM, but it just to make
> the point that LQM is Good Stuff.
Yes, but a bit tough on broadcast, as you would need all nodes sending a
history of all the other LQM counts it heard. Quite a big packet or set
of packets with many nodes participating.

You need to send one unicast packet to each ARP entry. You only want
a count of packets sent to that destination. You need to keep a
packet count per ARP entry and send it unicast. For example, MCI
doesn't need to count how many packets ANS sends to PSI (on a
gigaswitch they can't).

What might be a better idea is to add it to BGP-n. Say between routing
peers. That's what I did for IPng, in my (now mangled) Neighbor Discovery.

BGP is at a high level. LQM needs to be at a very low level to get an
accurate count.

> In the absence of LQM we have the DS3 MIB (poor substitute)

Hey, the original PPP LQM was designed and built for DS3 (at Network
Systems). NSFnet was very interested at the time. Aren't we already
running PPP LQM for all the DS3's?

IP over HDLC.

          Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2