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

From: "Tom Mistretta" <[email-masked]>
Date: Mon, 28 Nov 2005 10:44:37 -0500

The value in this tag was not added just for convenience.

- While I am not going to defend it, it's possible to use jumbo-frames
larger than 1500 (as opposed to in-between 1492 and 1500).

- Additional negotiations and retries during LCP shouldn't be
trivialized.

- PPPoE has had a troubled history, partially due to assumptions that
were made by different implementations (MxU, retry behavior etc).  The
use of an unqualified flag runs the risk of continuing that trend,
either by placing assumptions on values or overloading the flag for
other purposes.

We are advocates of the specific value.

Tom
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Peter Arberg
Sent: Sunday, November 27, 2005 9:16 PM
To: 'Paul Jakma'
Cc: [email-masked]
Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt

snip..

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

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.

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

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.

> I.e. To my mind, adding ability for intermediaries to inject a hint 
> 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 
> this hint?

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.

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

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

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

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

> > 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.
> 
> Well, see above for at least two problems with this 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.
> 
> We could turn the poll the other way around:
> 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

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

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

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

---

From: Paul Jakma <[email-masked]>
Date: Mon, 28 Nov 2005 23:39:14 +0000 (GMT)

Hi Tom, Peter,

> - PPPoE has had a troubled history, partially due to assumptions 
> that were made by different implementations (MxU, retry behavior 
> etc).  The use of an unqualified flag runs the risk of continuing 
> that trend, either by placing assumptions on values or overloading 
> the flag for other purposes.

The flag would return PPPoE to normal PPP wrt the default and MxU 
negotiation (which would /not/ be needed for 1500 - it'd be the 
default). Anything greater requires LCP negotiation as per normal 
PPP, as does the draft btw.

I think this is an opportunity to /reduce/ divergence of PPPoE from 
PPP. Previous divergence in PPPoE is exactly why this draft is 
required. Introducing yet further divergence seems unwise to me, 
particularly when there appears to be no good protocol reasons for 
it.

The quality of implementation issues seem to be utterly irrelevant to 
me, if an implementation can not get:

if (Max-Payload tag present)
 	initial/default MTU is standard-PPP (1500)
else
 	initial/default MTU is RFC2561 (1492)

right, it has bigger problems, and I'm not sure how you could trust 
that such implementations would describe the value they intend to use 
in Max-Payload correctly.

I can easily imagine an implementation being coded to think that the 
Max-Payload value indicates a /default/ MTU, that it can specify 
values in this field and then /not/ have to do LCP negotiation for 
that value (which the draft requires). That seems quite plausible 
given the concerns regarding ability to implement reliably even just 
the above psuedo-code.

I.e. adding a value just /increases/ the scope for assumptions, imho.

> We are advocates of the specific value.

Well, I've given my feedback. I obviously disagree, but I'll leave it 
at that and defer to experience of implementors.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The gent who wakes up and finds himself a success hasn't been asleep.