bcast LQM

Tue Oct 24 17:09:15 UTC 1995

In message <1904.bsimpson at morningstar.com>, "William Allen Simpson" writes:
> > From: Curtis Villamizar <curtis at 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.

> Bill.Simpson at um.cc.umich.edu
>           Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Curtis