Re: [Pppext] LCP echo request/reply support over multilink interface (RFC 1990)

[James Carlson <[e-mail]>]

Y Prasad wrote:
> I'm unable to parse that statement.  Could you provide specifics on how
> running LCP Echo-Request at the bundle level provides some sort of
> performance improvement?  Or at least what link flaps have to do with
> the problem?  I cannot see how that's so.
> 
> Yp> LCP keep-alives help to identify faulty link and peer state
> (alive/dead).
> If an user depends on link Career detect (or some other means) to
> identify faulty link, he may opt for no-keepalives on that link. And in
> order to identify whether peer alive or not just a bundle keep alives
> are good enough. This would reduce control traffic and flooding of LCP
> keep-alives on multiple link flaps/bundle flaps when links rejoin into
> bundle after LCP.

If the user can actually rely on the underlying medium-dependent health
checks, then I don't see what LCP Echo-Request would do at the bundle level.

If the peer is working, then those links should all be healthy, right?
And if the peer fails for some reason, then the links would (since
they're assumed to be reliable) indicate the lack of health, wouldn't they?

In order for LCP Echo-Request at the bundle level to be interesting, we
need to be in a world where the peer can fail completely but leave all
of the links "up," and where the only way any individual link alone
could fail would be something that is detected by the lower layer.

I suppose that's plausible, though I've never seen such a thing in
practice.  All of the systems I've seen have possible failure modes
where links remain "up" at the lower layer, but are not actually usable
for PPP for one reason or another.

As for the claimed control traffic reduction, I still don't get it.  If
a bunch of links go down, you're going to have to renegotiate LCP when
the links come back.  That's a given; it's part of the protocol.  LCP
Echo-Request (whether implemented or not) is no part of that process.
It has nothing to do with it.  In a typical implementation, you don't
bother with LCP Echo-Request at all until some time well after the link
has been established and has been passing data.

Thus, using LCP Echo-Request doesn't slow down the work in
reestablishing the bundle, nor does it impose any greater workload on
that case.

Even if there were such a traffic reduction (I don't believe it to be a
correct analysis), the two solutions can be made equivalent in terms of
overhead in a trivial way.  If you're going to send LCP Echo-Request
messages on the bundle at interval "M" seconds, and that interval is an
acceptable amount of traffic to you, then you can equivalently send LCP
Echo-Request messages at the per-link level at interval "M*N" seconds
(where N is the number of links in the bundle).

The overall message rate is the same.  No savings.  The only difference
is the kinds of errors you can detect.

> Yp> I agree in case member links are "bad" (meaning can not reflect
> faulty link properly).
>  "good link" here means it does reflect its faultiness without the need
> of LCP keepalives.

How do you know for certain that each of the member links can always
indicate whether they're capable of carrying PPP traffic without
significant error or delay?

And if they're able to do that, then why can't they also tell you
whether the peer is working at all?  That's the only remaining case --
that the peer is completely dead -- that bundle-level LCP Echo-Request
can detect for you.

> Even if it were made mandatory, that'd still just be in the new
> document, and there are many devices out there that are designed to RFC
> 1990, and might never be changed.
> 
> Yp> I agree. Only way is bundle-keepalive need to made as optional and
> negotiable attribute. Then it would work with existing installations.
> down-ward-compatible :).

So you'd be OK with not using LCP Echo-Request on existing platforms, right?

I guess I can agree that if you had a negotiation, you would know
whether you could default LCP Echo-Request operation to "on" or "off"
based on the outcome of the negotiation, without needing operator
intervention.

I'm not sure I see the lasting value in this, given the circumstances,
but ok.

For what it's worth, there's a poor-man's approach to this problem.
When you contact a new peer, you can assume that LCP is still in a
pretty good state one millisecond after it goes to Opened state.  When
you establish your first bundle with a novel peer, send a few LCP
Echo-Request messages over the bundle at some nominal interval (say,
three messages at three seconds apart).  If you receive any replies,
then you can assume that the peer does implement the feature, and you
can then continue to use it, and perhaps record that fact for that peer
in stable storage.  If you receive no replies, then you can assume that
it doesn't implement the feature, so you'll need to disable it.

The messages themselves can be all the negotiation you need.  And, best
of all, this approach works with existing equipment, and needs no new
document.

> Yp> I think we can club this rectification along with any other if any.
> Just for this writing an another draft may not be worth trying :)

OK.  It's up to you ... or any others who might be interested enough to
work out such a document.

-- 
James Carlson         42.703N 71.076W         <[e-mail]>