Karl Fox writes:
> Let me speculate: Is it because the customers are ISPs who started
> out with serial modems carrying PPP, and who now are so ossified by
> their legacy serial-centric back office systems that they want every
> new technology to look exactly like a serial modem? Or is there a
> real technical need that I haven't grasped yet?
Even if the reason is the former, that's not a very good argument for
adding the flow control bits here. (Why not add credits to the IP
header? Or add special radio signal and battery life extensions to
TCP?)
The more benign answer (expressed by others so far) is that PPPoE was
an available solution that could be modified to work in this
environment.
The aspect that I don't like about it is the idea that this somehow
makes it "cheaper" to modify PPPoE to solve the problem. I don't
think it does. What does happen instead is that every vendor who has
begrudgingly added support for PPPoE ends up being told by customers
that this new "performance extension" documented in RFC XXXX is
'required' for deployment. In other words, those who are completely
uninvolved in the local world of radio-based Ethernet bridges end up
tithing towards supporting that niche.
Stupid question time: why are these inherent radio-caused flow control
issues _not_ a problem for 802.11 and related technologies? Why is it
that this one radio technology requires special flow control
considerations in *other* equipment outside of that domain, but 802.11
does seemingly the same task and doesn't require special support?
Or are these issues an unresolved (and until-now unrecognized) problem
with 802.11 that simply must be handled at higher levels?
--
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
|
