Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational)

From: Vernon Schryver <[email-masked]>
Date: Wed, 27 Jul 2005 10:35:35 -0600 (MDT)

What?  That's not the draft I thought it was.  How stupid can I get?

Having now bothered to read it, I can't help wondering what PPPoE has
to do with the problem or the solution.  Why can't you do the same
things without having wasting precious radio bandwidth on 802.3 headers
and trailers?

I'm confused by the diagram and words in the introduction.
If I take the diagram literally, I wonder:

    Why don't the ends of the RLP link in the diagram in the introduction
    need their own authentication, authorization, etc. controls on
    access to the radio link?  If they do, then why wouldn't it be
    better have 3 separate PPP sessions?  If so, then why is it necessary
    to modify the PPPoE protocol?

    Are there any realistic hope that the vendors of the boxes
    labelled "Access Conc." ship such changes to PPPoE?
    If not, isn't that another reason to have 3 separate links?

    It seems to me that there is a continuing, fundamental confusion about
    network layers here and in the draft I thought was at issue.  The
    confusion is in seeing PPPoE as something above the link layer and
    equivalent to IP.  This and that other draft seem to view PPPoE frames
    as packets that should be shipped half way around the world through
    all manner of gateways, routers, and forwarders.

    This draft talks about "efficient routing" using the "link metric
    mechanism." Is that a wedge to introducing some kind of routing protocol
    into PPPoE?  I don't see much else in that vein in this draft, but it
    sounds like a start toward recapitulating link state vs. distance
    vector etc.  and so forth and so on.

    If instead you have 3 separate link-layer links, 2 PPPoE and one other 
    above or otherwise involving "RLP", you could use things are already
    tolerably well understood.  You'd probalby need to assign IP addresses
    to the Host Radios

But on second thought, it makes no sense that the pair of stationary
access concentrators should be connected via mobile radios.

Contrary to the diagram, is the idea to have new access concentrators
that talk via radios to mobile hosts, with IP over PPPoE over RLP? 
Is the diagram more about layering that links between boxes?
If so, why do you need PPPoE?

Vernon Schryver    [email-masked]

_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: Mark Lanzo <[email-masked]>
Date: Wed, 27 Jul 2005 13:24:34 -0400 (EDT)

> things without having wasting precious radio bandwidth on 802.3 headers

It's not PPPoE end-to-end between the PPP endpoints.
Unlike regular PPPoE, the termination point of the PPPoE and PPP don't 
coincide anymore.  The radio is merely creating an illusion of this to its 
attached router.  PPPoE is running between the router and its
host radio, not between the router and a peer router.  The flow
control, for example, is not one PPP endpoint giving credits to the
other endpoint, it is merely the radio telling its attached router that
it has available buffer space to take more packets. 

PPPoE is really just being used as a means to multiplex multiple
PPP sessions over the ethernet link to the radio, and as a carrier
for signalling info between radio and router.

The packets over the airwaves aren't PPPoE in nature, and for that matter 
how the remote PPP device talks to its host radio might be entirely 
different than the local end (the remote device might have a built-in
radio and simply see "RLP" as its native encapsulation for example,
and handle flow control far more efficiently than the other end with
its ethernet-connected radio).

A completely new protocol could have been devised for all of this,
but since the nature of the info traded by that protocol would have
been very much like the nature of the info traded by PPPoE, I think
the authors wanted to use PPPoE precisely so they wouldn't be
completely reinventing the same old wheel.  The purpose of the document
isn't to make a general-purpose extension to PPPoE, it's to create
a special purpose extension for a very specific sort of environment.

Lest I sound too authoritative, I should qualify that this is my
understanding based on past discussions I've had with the group
which is behind this draft.

-Mark Lanzo

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 27 Jul 2005 11:36:58 -0600 (MDT)

> From: Mark Lanzo <[email-masked]>
> To: [email-masked]
> cc: [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked]

> for signalling info between radio and router.

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?

> a special purpose extension for a very specific sort of environment.

So why not use the official IETF standard way to link networks instead
of piling kludges on top of the kludge that is PPPoE? 

The IETF standard way would be to give the routers IP addresses and
use a real routing protocol (or even static routes) instead of what
looks sounds like a retread of IGRP.  You might use PPPoE (or not)
between the access concentrators and their neighboring stationary
radios.  You might define a PPP over RLP encapsulation that would have
credits, battery condition, and so forth among the radios.
Wouldn't that produce products with a wider potential market as well
as fewer nastinesses such as an MTU that is even smaller than the bad
old PPPoE MTU of 1492?

Why egregiously violate layering by trying to convert IEEE 802.3
into an inter-network protocol?

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Jul 2005 19:52:12 -0400

On Jul 27, 2005, at 12:35 PM, Vernon Schryver wrote:
> Having now bothered to read it, I can't help wondering what PPPoE  
> has to do with the problem or the solution.  Why can't you do the  
> same things without having wasting precious radio bandwidth on  
> 802.3 headers and trailers?

AFAIK, it isn't. It is using the Ethernet as a local interface  
between a router and an interface device that has a number of special  
characteristics and is implemented in a separate chassis. Call it  
"system engineering" if you like. The actual protocol over the  
airwaves is PPP as known and loved, far more compact than PPPOE.  
PPPOE is simply used to manage the local interface between the router  
and the radio interface.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 27 Jul 2005 18:50:29 -0600 (MDT)

> Cc: [email-masked], [email-masked], [email-masked],
> From: Fred Baker <[email-masked]>
> To: Vernon Schryver <[email-masked]>

> PPPOE is simply used to manage the local interface between the router  

Ok, so why not assign IP addresses (perhaps by RFC 1918) to those 
those boxes with radios and PPPoE links to access controllers?

If this particular use of PPPoE as an inter-network protocol makes
sense, where does does using PPPoE as a replacement for IP not make
sense?

If PPPoE is not going over the radio waves, why are the access controllers
distinct boxes from the boxes ("radio interfaces"?) that connect PPPoE
to the real ether?

I suspect they are distinct boxes from the mention of the use of PPPoE
as a (de)multiplexing tool, which gets back to the evil of using PPPoE
as an inter-network protocol instead of IP.

---

From: Bo Berry <[email-masked]>
Date: Wed, 27 Jul 2005 22:54:40 -0400

Mark, well said!  PPPoE was selected for these reasons and
the fact that we could leverage the features of PPP at the
endpoints.  The extensions are optional and only come
into play when both PPPoE endpoints support the new
extensions.

-Bo Berry

---

From: Bo Berry <[email-masked]>
Date: Wed, 27 Jul 2005 23:03:31 -0400

in-line

> distinct boxes from the boxes ("radio interfaces"?) that connect PPPoE

We needed a means to control the eb-n-flow of packets between the
router and the radio independent of PPP.  So each router-radio,
radio-radio (RLP) and radio-router link provides flow
control relative to its segment.  PPPoE fit the overall model.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 27 Jul 2005 21:09:45 -0600 (MDT)

> From: Bo Berry <[email-masked]>
> CC: [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked]

> control relative to its segment.  PPPoE fit the overall model.

How is using PPPoE for flow control independent of PPP?

Aren't there existing, standard ways to do traffic shaping that would
not require extensions to PPPoE?
What about the reliable link flavor of PPP?  Why wouldn't it provide
flow control on its segment out of the box?

---

From: Bo Berry <[email-masked]>
Date: Thu, 28 Jul 2005 08:45:41 -0400

> flow control on its segment out of the box?

Flow control at each segment was required as compared to
relying solely upon PPP.  PPP flow is at a different point
of control.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 28 Jul 2005 07:36:58 -0600 (MDT)

> Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational)
> Cc: [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked]

> relying solely upon PPP.  PPP flow is at a different point

I do not understand that paragraph, unless that is again viewing PPP
as an inter-network protocol instead of a link protocol.

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Jul 2005 19:16:53 -0400

> flow control on its segment out of the box?

no.

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. This is not traffic shaping  
in the usual sense, as it is not attempting to smooth bursty traffic  
nor is it imposing a rate in the sense of "mumble bps forever". What  
it is doing is letting the interface implementation tell the queuing  
implementation how much traffic it may try to send at the rate the  
radio happens to be sending at *right*now*.

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Jul 2005 19:10:24 -0400

what, precisely, does "assigning an IP address" have to do with "rate  
control"?