North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: bcast LQM
In message <[email protected]>, "William Allen Simpson" writes: > > From: Curtis Villamizar <[email protected]> > > 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. > [email protected] > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Curtis
|