Fred Baker writes:
> I'll remind you of a statement earlier in the thread. The objective
> was specifically *not* to impose reliability on the link in the sense
> that LAPB or TCP are reliable. The objective was to provide a way
> that a system-engineered interface could advise a higher layer entity
> in a different system implementation (connected via Ethernet) of a
> rate at which it was permitted to send.
In other words, flow control of Ethernet traffic.
Here are the issues I see:
- What exactly do we do if there's more than *one* L2 link in the
path between these two nodes that requires flow control?
- Isn't this a more general problem with bridged Ethernets using
different-speed links? Why is a point solution acceptable in this
one case where the real problem is that there's no end-to-end flow
control mechanism in Ethernet networks?
Apart from the questions of endpoint parameter assignment (which I
think are more than adequately dealt with using existing protocols,
such as DHCP, rather than pressing PPP into service in non-point-to-
point applications) and authentication (802.1X), the purpose here
seems to be to use PPPoE just because it could be extended to provide
a flow-control mechanism.
In short, it seems to be a local "optimization" that would have little
general usability, would likely complicate other's implementations for
no good reason, and would even inhibit or conflict with real solutions
to the problem. (If bridging over these radios is an important
solution space, and if the lack of buffer space and variance in
transmit access times are such that per-peer flow control is a
requirement, why isn't this dealt with either in the radio itself or
in the way bridging is run in these special cases, or even as a
general 802 problem?)
It seems to me like PPPoE is being used as a willing victim.
The reason *I* mentioned RFC 1663's LAPB was that I was a bit
surprised that the document contained no actual references to other
solutions in the same area. At least I think it would help to be able
to say "we considered LAPB framing as part of the mechanism rather
than inventing our own credit-based scheme and header changes and
network monitoring gear to go with it, but LAPB cannot be extended to
omit retransmission and do flow control alone because of <X>."
I can't quite fill in that <X>, though.
Mark Lanzo writes:
> On 27 Jul, Vernon Schryver wrote:
> > Which raises my question of what PPPoE has to do with the solution
> > and my point that PPP(oE) is widely misunderstood as other than a
> > link layer protocol. Why use PPPoE to link networks instead of IP?
>
> The proposal *is* using PPPoE as the link layer. If anything, more
> than PPPoE is normally used as such.
That doesn't answer the "why" question. IP runs fine over Ethernet.
> The whole point is that you have a router and an external radio.
> The radio has an ethernet port on it, by which it attaches to the
> router. The radio itself detects other radios in its vicinity,
> and creates a semblance of a serial connection to each of those
> adjacent radios. The customer wants the router to run PPP on these
> serial connections.
It's that "semblance" that I think is a problem here.
> The serial links have to be simulated at the router end. Bottom line
> being that the ethernet is really just a funky "backplane" here, and
> the goal is to couple the router as close as is reasonably possible to
> its "serial" ports.
I think that's an oversimplification in at least one area: if the
radio can speak Ethernet to each of the end nodes, why do you care
about having any mesh of "serial ports" overlaid on this topology?
IP already works on Ethernet, and just sending IP/Ethernet packets to
those remote destinations ought to work fine over any useful bridge.
What seems to be missing is that this device, although it tries to be
a bridge, just isn't a very good Ethernet bridge; it lacks the burst
handling and flow control characteristics that would make it good
enough to use. I'm not sure that papering over that problem by
creating a complex web of additional layered protocols (plus a
smattering of *new* protocols that need to be implemented and tested)
is the right way to solve that problem.
> I understand why you think of PPPoE as a kludge, and can understand
> reluctance to propogate use of a kludge. Still, it seems to me that
> if anything that the intended use here is a better use - less of a
> kludge - than PPPoE as it is normally deployed.
That's the point where we disagree. The way I read it, you've already
assumed that a mesh of point-to-point connections is the right
representation of this topology, and that PPPoE follows naturally from
that. I agree that if that topology is part of the requirements
somehow, then this answer is _perhaps_ less awful than others, but I
don't see why it's actually required.
> "backplane" to the radio. The fact that the packets contain PPP frames
> is barely relevant. Unfortunately, describing the proposal as an
> extension to "PPPoE" seems to be having a very negative effect, because
> it brings with it all the negative baggage associated with PPPoE.
No, I don't think that's the problem.
Plus some of the issues (such as the MTU problem) occur *BECAUSE* this
is the chosen solution, not because of any negative connotation of
PPPoE.
> > So why not use the official IETF standard way to link networks instead
> > of piling kludges on top of the kludge that is PPPoE?
>
> What standard official IETF way of multiplexing virtual serial
> connections over an ethernet (or any media) "backplane" are you
> referring to?
I don't think that's the right question at all. The official IETF
standard way of running IP over Ethernet, though, is documented in RFC
894.
> > Wouldn't that produce products with a wider potential market
>
> Just the opposite, actually (hopefully). Routers already exist which
> support PPPoE. Using PPPoE in this rather unusual fashion means the
> ability to hook these specialized radios into existing router equipment.
None of the existing PPPoE implementations support this credit scheme.
What to do about them?
> Significantly improved performance is gained for those routers which
> implement the proposed extensions. It seems more likely that manufacturers
> would augment already developed PPPoE implementations than implement a
> whole new protocol.
This *is* a whole new protocol.
I think you're arguing that they're already familiar with PPPoE and
are thus comfortable with hacking on that. I'm not convinced that
this is really a good way to make architectural decisions about
networking protocols.
It's all too easy to run into the hammer problem: when all you have is
a hammer, every problem begins to look like a nail.
> That is admittedly still an issue. As long as the "backplane" to the
> "radio card" is an ethernet, it doesn't seem easy to avoid this (short
> of resorting to some form of link layer fragmentation). It is also
> a bit off-topic since this is a technical limitation not arising from
> anything within the draft itself, well understood, and which the draft
> makes no claim of trying to overcome.
I don't think it's off-topic at all. It's right on topic for the
question of whether the proposed solution is solving the right
problem.
> > Why egregiously violate layering by trying to convert IEEE 802.3
> > into an inter-network protocol?
>
> Hopefully it is clear by now that the above statement is inaccurate,
> and arises from misperceptions about the proposed mechanisms.
I don't think it's really all that inaccurate. There are flow control
problems here directly due to the implementation choices.
> As I indicated above, it seems to me that there is a lot of reaction
> to this draft, but the reaction is due (at least in part) to the bias
> against traditional PPPoE and not due to the technical merits (or lack
> thereof) of this proposal or its intended goals. My thought is that the
While I'm no fan of PPPoE (having implemented it in Solaris), I don't
think this is true. I just see wider issues here that aren't being
properly addressed.
--
James Carlson, KISS Network <james.d.carlson@xxxxxxx>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
Pppext mailing list
Pppext@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext
|
