James Carlson wrote:
> Bo Berry writes:
>
>>>>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?
>
> [...]
>
>>Correct, 802 is not in the draft. In fact the extenstions are
>>independent of the radio technology.
>
>
> So, then, at least my stupid questions are still valid. Why does this
> draft provide a solution for something that's not generally recognized
> as a problem with 802.11? What has made it necessary in this
> instance? I'm missing something because it seems like the issues
> ought to be more alike than not.
>
>
>>The radio terminates the PPPoE session and forwards the PPP frames
>>over the airwaves. The frames are transported by the radio
>>independently of the PPPoE. The radio requirement is that it
>>can associate both ends of the radio channel, by whatever
>>means/technology is required in the radio. The overall
>>requirement is that PPP flow be maintained, end to end.
>
>
> That makes the requirements even less clear to me. If this device is
> essentially doing routing with a mesh of point-to-point links, why
> doesn't it actually behave as a router? Why is it instead a PPP
> bridge that exposes internal implementation details (the operation of
> the radio link) to other Ethernet devices? And why is it dependent on
> the use of PPPoE outside of this domain?
>
> If it were used with something other than IP+PPP+PPPoE (i.e., bridging
> arbitrary LANs together, perhaps running some 'foreign' protocol such
> as MPLS), what happens? Does every Ethernet-based protocol need an
> upgrade to handle credit-based flow control so that this radio link
> will work correctly?
These extensions are optional and are not required by existing
PPPoE implementations. Systems that require flow control
through (certain) radios could employ this solution. We do
not want the router to overrun the radio buffers, nor do we
want the radio to overrun the router, hence the need for
flow control (via credits).
>
_______________________________________________
Pppext mailing list
Pppext@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext
|
