RE: comment on draft-arberg-pppoe-mtu-gt1492-02.txt

Hi Peter,

On Fri, 25 Nov 2005, Peter Arberg wrote:

> The problem is that not all PPP hosts do perform a MRU negotiation, 
> it is optional. And further more we also have seen PPPoE clients 
> who perform a MRU negotiation of 1500 but can not accept the value.

That's fine though surely?

If a client doesn't do negotiation (e.g. it doesnt or isnt capable of 
> 1492 MRU/MTU), it doesn't negotiate. Simple. The MRU is 1492, 
unless it indicates it's a 2561bis PPPoE implementation by adding the 
tag, in which case normal PPP defaults apply.

As for clients getting it wrong, what's to prevent them getting it 
wrong if Max-Payload also carries a value? One would hope though that 
any PPPoE implementation which is updated to support either a 
Max-Payload or "Ignore the 2561 limit tag" is then tested to make 
sure negotiation (as well as 1500 default) actually works.

> The PPPoE MRU Tag is intented for 2 purposes, the one is for 
> "normal" PPPoE clients who wish to negotiate a higher MRU, and as 
> such this is a way for the BRAS to know this is a new client and it 
> is safe to negotiate above 1492, all the way up to the Max-Payload 
> value, yes this could have been handled with out the value, with a 
> simple flag Tag, if we could be sure all clients will perform MRU 
> negotiation.

See above, why ever would an implementation be updated to include a 
tag and then /not/ support either the PPP 1500 default, or 
negotiation if larger sizes were desired?

If the problem is quality of implementations, then adding further 
variables into the mix (an additional "Max-Payload" value) does not 
seem any more likely to improve their quality ;).

> interworking device, and initiate the PPPoE discovery phase. In 
> this case the DSLAM knows we are dealing with a PPP(oA) host and as 
> such can send the Max-Payload value of 1500. Could this have been 
> handled with a simple flag Tag, yes I guess it could.

Right.

Unless you're envisaging that the "Max-Payload" is /not/ known to the 
BAS, but only to some DSLAM further along the path. In which case I 
can see why you'd want a DSLAM to be able to 'interject' and add this 
"Max-Payload" hint. However, the draft seems to envisage that PPPoE 
will be run between DSLAM and BAS, hence the BAS /is/ quite aware of 
it - and there was mention before that the path MTU would be known 
in advance to the operators.

Even so, such case, to my mind, would raise further questions about 
exactly /who/ is allowed to add Max-Payload along the way, whether 
Max-Payload may be replaced if it already exists (only downward 
change makes sense I guess) and error cases. Etc. None of which is 
covered in the draft, afaict.

> The problem is inbetween, I know it is proabably not a real life 
> situation, but you never know, if a "normal" PPPoE client can 
> handle higher than 1492, but can not handle 1500 ?? agree sounds 
> far out, this case could not be handled without the value in the 
> Tag, as long as you not know for sure that the client will perform 
> a MRU negotiation, and many don't.

Why would a PPPoE implementation be updated to support a 
"Ignore-2561-MRU-Limit" tag and then not support either the default 
of 1500, or any other negotiated MRU? :)

> So as far as I remember, this was the reason along with the fact to 
> streamline the MRU negotiation, where the BRAS knows what value to 
> suggest in the initial MRU negotiation so it do not have to go back 
> and forth, it was an intention to help speed up the negotiation.

How much of an overhead would this be really, compared to the rest of 
PPP LCP and IPCP? (Which already is pretty much "instant" on decent 
links, at least as far as a human can tell).

Further, isn't it likely that the vast majority of deployments will 
simply use the default 1500 PPP MxU? In which case no negotiation 
would be needed at all.

> And then we never saw it as a problem to include the value, and 
> neither did any of the PPPoE client vendors we discussed it with, 
> agreeing to include a new PPPoE Tag was the biggest problem, the 
> value seemed a small topic compared to that.

The tag seems uncontraversial, its required to signal the lifting of 
a quite needless/silly restriction in 2561. However inventing 
additional MxU negotiation mechanisms on top of that, when PPP 
already provides:

a) The value nearly everyone will want to use (1500) as a *default*

b) A perfectly fine MRU negotiation mechanism[1]

Seems redundant.

If there is no need for it, then why include it? If so: at best it 
does no harm and nothing else, at worst it's yet another thing for an 
implementation to get wrong, no?

Including a value is also more baggage for future RFC authors to 
potentially have to consider wrt backward-compatibility issues - 
having just a 'flag' tag reduces PPPoE back to normal PPP wrt MxU (so 
even if future RFC authors fail to consider that tag and only 
consider 'plain' PPP, it won't make any difference).

I.e. I think it just might be simpler all round to /not/ include a 
value, unless there is a pressing reason to do so. "Well, it's easy 
to put a value in there" doesn't seem a good enough reason - what 
problem does it solve? If none, why add it?

> cheers,
> Peter

1. Which is what should have been specified for the 1492 MTU which 
2561 wanted, rather than encode it as a hard-limit into the RFC, then 
we'd not be having this conversation now. ;)

regards,
-- 
Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
Fortune:
"What if" is a trademark of Hewlett Packard, so stop using it in your
sentences without permission, or risk being sued.

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