Subject: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt

From: Paul Jakma <[email-masked]>
Date: Thu, 24 Nov 2005 10:07:29 +0000 (GMT)

Hi,

I have a question about this draft:

Why would it not suffice to simply specify a "I can ignore the 
RFC2516 1492 limit" tag in PADI and PADRs? Indeed, why do you even 
need to signal this? :)

The problem, AIUI, is not a lack of a MTU-negotiation feature in PPP, 
but just that limit. So all that needs to be signalled is the removal 
of that limit, rather than an additional MxU value - if it even needs 
to be signalled seperately..

Signalling an additional value seems to complicate things to my mind, 
further it raises questions about exactly what it represents (ie the 
MxU of which underlying link exactly?) and who should be setting it 
(the DSLAM, the BAS? What if both want to set it?).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The last thing one knows in constructing a work is what to put first.
   		-- Blaise Pascal

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

---

From: "Peter Arberg" <[email-masked]>
Date: Thu, 24 Nov 2005 14:52:14 +0100

Hi Paul,

I have answered your questions inline in the email.

> RFC2516 1492 limit" tag in PADI and PADRs? Indeed, why do you even 

This was discussed initially, as it was also our first thinking,
but for optimization purpose it was suggested to include the
max. payload number as well.  

The idea of the new option was to have the PPPoE client communicate 
in the PADI and PADR the maximum MTU/MRU it can deal with. Then the
PPPoE server will have a good hint to immediately select a proper
value for the MRU to propose in its LCP config_req. This would make 
the regular case more streamlined.

> to be signalled seperately..

Correct, this is simply a message from the PPPoE client that it can 
handle a PPP MRU negotiation upto limit-value.

> (the DSLAM, the BAS? What if both want to set it?).

It was not the intention to complicate things, simply to make the 
negotiation more streamlined. And when the TAG had to be included, it
did not seem like an issue to include the max MxU number.

The number is only to be set by the PPPoE client side, never from
the server (BRAS) side, the PPPoE server will echo the clients value
back as a okay lets do PPP MRU negotiation to settle on a value.

cheers,
Peter

---

From: Paul Jakma <[email-masked]>
Date: Thu, 24 Nov 2005 14:13:31 +0000 (GMT)

On Thu, 24 Nov 2005, Peter Arberg wrote:

> but for optimization purpose it was suggested to include the max. 
> payload number as well.

I did try look over the previous discussions, I read the thread where 
it was suggested to introduce new tags, I didn't see any discussion 
of including a payload size though - never mind the rationale for 
doing so.

> the regular case more streamlined.

Right, I did read the RFC. ;)

It doesn't give any rationale for why it's a good idea to include a 
"Max-Payload" value in the tag though.

> negotiation more streamlined. And when the TAG had to be included, 
> it did not seem like an issue to include the max MxU number.

It's an additional piece of state for:

a) implementations to have to track and hence get wrong

b) future refinements to have to bear in mind wrt
    backward-compatibility.

Making it be just a "remove the RFC2561 limit" flag simply reduces 
things back to normal PPP, at least wrt MRU/MTU negotiation.

> the server (BRAS) side, the PPPoE server will echo the clients 
> value back as a okay lets do PPP MRU negotiation to settle on a 
> value.

Why can't the client just start doing MRU/MTU negotiation as part of 
PPP setup, as it will have to do anyway? Why add an additional value 
into the mix?

This Max-Payload value seems quite redundant.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"The medium is the message."
-- Marshall McLuhan

---

From: "Peter Arberg" <[email-masked]>
Date: Fri, 25 Nov 2005 00:38:06 +0100

> -----Original Message-----
> From: Paul Jakma [mailto:[email-masked]] 
> Sent: 24. november 2005 15:14
> To: Peter Arberg
> Cc: [email-masked]
> Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt
> 

sorry, should have said, discussed initially between co-authors and 
people in the ack. section..

> PPP setup, as it will have to do anyway? Why add an additional value 

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.

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.

The second case is the setup where a DSLAM will act as a PPPoA to oE
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.

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.

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.

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.

cheers,
Peter

---

From: Paul Jakma <[email-masked]>
Date: Fri, 25 Nov 2005 07:20:31 +0000 (GMT)

Hi Peter,

On Fri, 25 Nov 2005, Peter Arberg wrote:

> 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 

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.

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

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

> 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-masked]	[email-masked]	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.

---

From: "Peter Arberg" <[email-masked]>
Date: Fri, 25 Nov 2005 13:38:45 +0100

Hi Paul,

I used a wrong word,

> > who perform a MRU negotiation of 1500 but can not accept the value.

It should have been "handle" instead of "accept".  We have seen
PPPoE clients negotiate MRU 1500, but can not handle packets received 
with a payload of 1500.

I agree on your comments, that the reasoning for the value is not
strong, it is the small differences there decided to add the value instead
of leaving the flag only.

1. handle all cases where MRU not negotiated, also a client between 1492 and
1500
2. set the hint for the MRU suggestion to speed up negotiation

I agree RFC2516 could have been worded different, and we would not
have had this draft at all, but that's history and difficult to change ;)

I'm not sure what "backward-compatibility issues" you refer to, but
remember that the value in no way removes or changes the PPP MRU
negotiation, it is simply a out-of-band hint for the PPPoE server
to what MRU max value the client will be able to handle, but the
PPP negotiation will be used to agree on this.

I have no problem making the value optional, so if the Tag is used 
with a 0-length data section, it will by default say a 1500 Max-Payload, 
but at the same time I do not see a need to change it unless there is 
more people who see a problem using the value.

It would be good to hear if anybody else on the list see a problem
with the inclusion of the value in the PPPoE Tag.

thanks,
Peter

> Sent: 25. november 2005 08:21
> To: Peter Arberg
> Cc: [email-masked]

---

From: Paul Jakma <[email-masked]>
Date: Fri, 25 Nov 2005 13:39:12 +0000 (GMT)

On Fri, 25 Nov 2005, Peter Arberg wrote:

> PPPoE clients negotiate MRU 1500, but can not handle packets 
> received with a payload of 1500.

Ah well. :)

> have had this draft at all, but that's history and difficult to 

Indeed ;).

> I'm not sure what "backward-compatibility issues" you refer to,

Nor do I, but adding special-cases to protocols is what makes them 
progressively harder to revise. Hence, try avoid adding them unless 
required.

> but remember that the value in no way removes or changes the PPP 
> MRU negotiation, it is simply a out-of-band hint for the PPPoE 
> server to what MRU max value the client will be able to handle, but 
> the PPP negotiation will be used to agree on this.

It's more than a hint, it's a "MUST" for the server. Further, what 
happens if the client is also PPPoE?

 	client<----PPPoE---->DSLAM<-----<PPPoE>----BAS

The PPP session (and LCP MxU negotiation) is between the client and 
BAS, but the DSLAM handles the PPPoE session. What exactly is to 
happen here wrt the Max-Payload value? It's not specified is it?

What happens if the right of the BAS looks like:

 					BAS---<PPP/l2tp/IP>----ISP

Where the BAS is essentially just punting the PPP session on /again/ 
to another ISP (this is, sadly, how wholesale DSL via 
$incumbent_telco is provisioned in my country). The DSLAM may not 
have visibility of the MTU of this latter link (which might not be 
same size as the other).

I.e. To my mind, adding ability for intermediaries to inject a hint 
opens the following questions:

1. What should occur if there are multiple intermediaries able to add 
this hint?

The answer to that is probably not too tough (only ever allowed to 
reduce Max-Payload). But leads to:

2. What if some of the 'segments' are not PPPoE? (And hence, not able
    to 'forward' this Max-Payload tag)

That one seems more difficult. ;)

You could answer 2 with "well, operators will know in advance what 
the path MTU is and configure it statically", which is (if we assume 
PPPoE is acceptable) fine - but then why bother with putting the 
value in? Further, what if the 'client' also transposes the PPP 
connection from one transport to another? It gets messy really 
quickly imho.

If you specify a mechanism to dynamically insert path-MTU hints into 
this PPP wrapper protocol then, IMHO, you also need to deal with the 
weird and wonderful ways this hint could be used, abused and 
interact.

> with a 0-length data section, it will by default say a 1500 
> Max-Payload, but at the same time I do not see a need to change it 
> unless there is more people who see a problem using the value.

Well, see above for at least two problems with this value.

> with the inclusion of the value in the PPPoE Tag.

We could turn the poll the other way around:

Does anyone think the tag should include the Max-Payload?

;)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Cheese -- milk's leap toward immortality.
 		-- Clifton Fadiman, "Any Number Can Play"

---

From: "Peter Arberg" <[email-masked]>
Date: Sun, 27 Nov 2005 21:16:21 -0500

snip..

> happen here wrt the Max-Payload value? It's not specified is it?

I do not understand your comment, the DSLAM handles the PPPoE session,
I think we have a slight misunderstanding here.

The DSLAM will not be involved in any native PPPoE sessions initiated
by a CPE equipment, and the Max-Payload Tag is only added by the 
PPPoE client who initiates the PPPoE discovery stage.

So in you picture the "client" adds the Max-Payload Tag value
and the DSLAM have no idea, and is not suppose to have any idea
of what is going on in a PPPoE session.

> have visibility of the MTU of this latter link (which might not be 

Yes this is a common PPP wholesale scenario, and the internet-draft
do not make any suggestions to how the PPPoE MTU hint should be
forwarded in the L2TP session.  We have had some multivendor
discussions on this with a few carriers, but the draft was not intended
to take care of this, as we initially wanted to make sure we could
increase the PPPoE MxU, and then another L2TP specific work can
take the next step and make sure to expand the work.

And yes we do have a suggestion to how this can be signaled in the
L2TP, but different place, different discussion.

> opens the following questions:

This is not intended, it is intended to be a client-server Tag only
no intermidiate systems should use/add or remove this tag.

> 1. What should occur if there are multiple intermediaries able to add 

They should not, this is only added by the client who initiates the 
PPPoE discovery phase, and used by/echoed back by the PPPoE server
who is the other peer in the PPPoE discovery phase.

>     to 'forward' this Max-Payload tag)

again, the tag is not intended to take care of the underlying L2
MTU of the network, this is why we make the note:
---
   The procedure described in this document do not strictly conform 
   to IEEE standards for Ethernet packet size, but rely on a widely 
   deployed behavior of supporting jumbo frames on Ethernet segments.
---

> weird and wonderful ways this hint could be used, abused and 

The Tag is a client-server information, not intended for any intermediate
systems, this is not any different than any other PPPoE tag defined.

> Does anyone think the tag should include the Max-Payload?

nice try, but read the draft again, as you can see at least 2 vendor
companies and 1 carrier are co-authors, in the ack. section several
other people from both vendor and carrier world is listed.

The draft have been presented on the DSL Forum meeting in Philadelphia
and no people objected to the value.

I have listed 2 major reasons why it was included, and there are
multi-vendor implementations today based on this suggestion in test
at carriers network.

I'm not saying this is a reason it should not be changed, I'm simply 
saying it shows that people have agreed to the suggestion, and we
need some real good reasons to change it, better than future
backward compatibility, and it seems more complicated than needed.

thanks,
Peter