Re: Review of draft-bberry-pppoe-credit (Informational)

in-line
-Bo


Vernon Schryver wrote:
>>From: James Carlson <[email protected]>
>>To: Karl Fox <[email protected]>
>>Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational)
>>Cc: [email protected], [email protected], Fred Baker <[email protected]>,
>>        Vernon Schryver <[email protected]>, [email protected],
>>        [email protected], [email protected], Mark Lanzo <[email protected]>
> 
> 
> 
>>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?
> 
> 
> I don't think that's a stupid question, because I have one that really
> is.  Exactly what bits are going over the air?  
> 
>   Is this about 802.11?  As far as I can tell, the string "802" does
>      not appear in draft-bberry-pppoe-credit.
Correct, 802 is not in the draft.  In fact the extenstions are
independent of the radio technology.

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.



> 
>   If not, what other headers, trailers, whatever are involved?
> 
>   Are there PPP headers and trailers in the air, and if so, what flavors?
> 
> 
> I also have a counterproposal.  Assume that traffic shaping of the
> sort needed is not available with other IETF protocols.  (I wonder if
> Fred Baker was right when he gave his "no" answer, because old style
> IP TOS and less old diffserv don't sound that different.)  What is
> special about PPPoE that makes credits and so forth need there but not
> in other PPP flavors?  I think there are other palces where it could
> be more valuable.  What about ABR ATM?--yes you could get a committed
> bit rate but that might cost more and blah blah blah.
> 
> So why do as was done with the multi-link protocol and add another new
> PPP sub-layer?  Or modify MP itself to have some control packets
> that would do the crediting?  Or extend LCP with some new types?
> 
> That would be a more general solution to the particular problem.
> It would also not burn more of the poor, withered PPPoE MTU.
> 
> 
> Vernon Schryver    [email protected]
> 

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