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

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Thu, 8 Dec 2005 10:56:17 -0500

James/All -- 

When viewed in the context of 802.11 radios, I would agree that the 
applicability of this draft is suspect. However, when viewed in the 
context of TDMA radios, that point-to-point characteristics, this 
RFC does seem applicable. 

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. 

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. 

Regards,
Stan

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of James Carlson
>Sent: Thursday, December 08, 2005 10:27 AM
>To: [email-masked]
>Subject: [Pppext] warning suggestions for draft-bberry-pppoe-credit
>
>Our AD has asked for some suggested warning text that can be added to
>this draft, as the author has asked for it to be published as an
>Informational RFC.  (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.)
>
>Here's my suggestion.  Feel free to suggest better wording.
>
>  "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."
>
>-- 
>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
>

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

---

From: James Carlson <[email-masked]>
Date: Thu, 8 Dec 2005 12:10:06 -0500

> 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.

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?

> states the applicability to TDMA-like radios, as opposed to what 

Please suggest some text, and I'll see what I can do with it.

-- 
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