I think this is a great idea. Of course, almost everything listed here
is already done with PPP LQM....
> From: Vadim Antonov <avg(a)pluris.com>
> a) dampening
>
PPP LQM does not specify any particular dampening algorithm, but gives a
simple N of M example.
> b) blackholing
>
PPP LQM allows you to send LQRs at some periodicity, and the interval
for two (2) round trips of these packets determines your blackholing time.
Of course, there is the issue of how you handle Loss of Signal, and
other such hardware indications that the link is down. Probably should
follow the 2 RTT rule. That's what my dialer code (in a fair number of
low end boxes) does for modem links....
> c) priority
>
At least in _my_ implementation, _all_ PPP control packets are sent at
the highest priority.
> d) sub-second keepalive intervals
>
Yes, Craig Fox, then at Network Systems (now at Cisco) wanted very high
rates for their T3 LQRs, even 4 years ago, thinking ahead. You might
want to thank him.
We settled on hundredths of seconds, matching the only thing supported
by SNMP at the time. Good enough?
> e) Link Quality Monitoring -- the usefulness is obvious.
Yes.
> One particluar case i have in mind
> suddenly increased link latency by some 400 ms (Satellites-R-Us,
> that's it), so manual intervention was required to move traffic
> off the link.
Now this is a good idea that we didn't think of. There is no time field
for measure of link latency.
But, it could be accomplished, by configuring _only_ one end to send the
LQRs. In that mode, sending an LQR will cause one to echo, and you
could measure the interval.
So, since we designed PPP LQM for the 56K, T1 and (new) T3s of 5-6
years ago (at least a generation in Internet lifetimes), why isn't
everyone already running it?
WSimpson(a)UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson(a)MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
