Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Thu, 8 Dec 2005 12:39:49 -0500

>-----Original Message-----
>From: James Carlson [mailto:[email-masked]] 
>Sent: Thursday, December 08, 2005 12:10 PM
>To: Stan Ratliff (sratliff)
>Cc: [email-masked]
>Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit
>
>Stan Ratliff (sratliff) writes:
>> It allows the radio vendors to do what they do best, and at the same
>> time, allows router vendors to do the same. Propagation of the P2P 
>> characteristics of TDMA links back into the router allows the router
>> to allocate QoS queues on a radio link-by-radio link basis, giving 
>> good granularity and control. 
>
>The point here is that Ethernet is Ethernet, and if this link requires
>the sort of explicit flow control described here, then it's most
>certainly _not_ Ethernet.  The problem is not at this layer.
>

Agreed. The intent of the draft is to use Ethernet/PPPoE to 
allow two devices, each having its own specialty, the ability to 
communicate with each other over a ubiquitous medium (Ethernet), 
and still preserve the characteristics of the RF transmission. 

>Either the radio itself needs to be fixed to provide the service it's
>claiming to provide, or it needs to abandon the pretense.  Providing a
>service that doesn't work as expected isn't helpful.
>
>Ethernet supports multiple protocols.  What would you do if someone
>ran some protocol *other* than PPPoE over this pseudo-Ethernet?
>Wouldn't you be forced to fix the problem all over again?
>

I don't understand what you mean here. In our implementation, the 
radio and router are connected via a real Ethernet, not a pseudo-
Ethernet. There is no intersection I'm aware of with other devices 
on the Ethernet communicating with each other via different protocols. 
The intent isn't to create a pseudo-Ethernet with the extensions,
rather, 
the intent is to create a group of pseudo point-to-point links,
representing
the individual TDMA radio links, tunneling over the Ethernet connection 
from radio to router. 

>> So, at the worst, I would like to see some text in the draft that 
>> states the applicability to TDMA-like radios, as opposed to what 
>> you have here. 
>
>Please suggest some text, and I'll see what I can do with it.

Ok, here's my shot at it: 

  "The techniques described in this document will not be applicable
  to all radio implementations. This document describes extensions 
  better applied to radios with point-to-point transmission 
  characteristics (e.g. TDMA). When used with multi-access, broadcast
  capable radios such as 802.11, these techniques may have unpredictable
  interactions with higher and lower layers."

Regards,
Stan

>
>-- 
>James Carlson, KISS Network                    
><[email-masked]>
>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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: James Carlson <[email-masked]>
Date: Thu, 8 Dec 2005 13:05:31 -0500

> the individual TDMA radio links, tunneling over the Ethernet connection 

It's Ethernet ... but with a kind of L2 backpressure mechanism that
regular Ethernet itself doesn't quite have.

My point is that if you had something *other than* PPP to transmit to
those nodes over the radio, then you'd be sunk.  You'd have to start
over because PPPoE carries only PPP.

Your assertion seems to rest on a particular deployment and
combination of protocols: PPP (and nothing else) between radio and
remote nodes, Ethernet (and nothing else) between radio and router,
and no way to implement the patently obvious solution -- just
terminating PPP in the radio and using regular L2 forwarding or IP
routing outside of that context.  No PPPoE required.

Its narrowness makes it extremely suspicious.  I agree that there may
well be a problem here that needs to be solved.  I'm deeply concerned
that this doesn't actually address the problem in any lasting way and
is instead a diversion for developers.

>   interactions with higher and lower layers."

How about:

  The techniques described in this document are intended for use with
  a particular deployment technique that uses a PPP termination
  separated from a radio termination by an Ethernet, and that has
  radio-side flow control for a slower PPP-only link to remote nodes.

-- 
James Carlson, KISS Network                    <[email-masked]>
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

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 8 Dec 2005 11:08:29 -0700 (MST)

>   interactions with higher and lower layers."

That text has nothing to do with the intent of the other text.  It tries
to apply the impremature of the IETF to the proposal.  It is also simply
wrong on technial grounds.  (e.g. "radios with point-to-point transmission
characteristics" is bogus.)  For comparison, here is the other text:

  The PPP Extensions Working Group (pppext) has reservations about
  the desirability of the feature described in this document.  In
  particular, it solves a general problem at an inappropriate layer
  and it may have unpredictable interactions with higher and lower
  level protocols.  The consensus of the working group is that
  implementors would be better advised either to seek ways of making
  the underlying radio link suitable for general Ethernet-like use, or
  to abandon the incomplete emulation of Ethernet entirely.

Unless alternate text that says that the WG *does not* like the
proposal and perhaps a little of why, the original text must be used.

As James Carlson also wrote:

]                         (Please -- no matter which side of this divide
] you're on -- direct your flames to /dev/null.  Yes, I and the rest of
] the folks here know all of the arguments on both sides.  We don't need
] to go over the issues again.)

Vernon Schryver    [email-masked]