Re: I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt

J. Fitzgibbon:

Agree with the interoperability concerns brought forth
by J. Carlson.  This is a real problem.  Also performance
gain from 1492 to 1500 in the scheme of things is negligible.

If you are really set on gaining 8-bytes, consider defining
optional tags to negotiate the extended/longer MTU.  This
method would be backward compatible.  Another suggestion
is to publish as an Informational RFC.

Good luck
B. Berry




James Carlson wrote:

>>	Title		: Accommodating an MTU of 1500 in PPPoE
>>	Author(s)	: J. Fitzgibbon
>>    
>>
>
>So, now that this is (finally) out, I have some comments.
>
>  
>
>>Abstract
>>
>>   Point-to-Point Protocol Over Ethernet, (PPPoE), as described in RFC
>>   2516, mandates a maximum negotiated MRU of 1492. This memo proposes
>>   relaxing that restriction to allow a maximum negotiated MRU of 1500.
>>    
>>
>
>Many implementations (including the one on Solaris) assume that if the
>MRU is not negotiated on a PPPoE link (or is rejected), then the
>default MRU is 1492.  Is that still true?
>
>Suppose one of these new implementations is negotiating with an old
>one.  The new one suggests an MRU of 1500.  The old peer looks at that
>and says, "well, I can't ever send a packet that big, but I'm glad he
>could accept it if I could, so I'll send Configure-Ack."  The old peer
>doesn't include the MRU option in its Configure-Request (as none is
>really needed).
>
>What MTU does the new peer end up with?  The answer can't be 1500, or
>interoperability is broken.
>
>  
>
>>   This can be achieved by treating the PPPoE Header and Protocol ID as
>>   part of the Ethernet Header, taking advantage of the fact that most
>>   network devices have buffers for the Ethernet Header and Payload that
>>   are at least 1522 octets in size. To aid backward compatability, the
>>    
>>
>
>This part seems like the wrong venue to me.  In order to get the PPPoE
>Session Stage Ethertype recognized as being in the same class of types
>as the VLAN tag, I think that the IEEE specifications have to be
>updated.  I don't think that extending Ethernet standards is something
>the IETF should undertake.
>
>  
>
>>   As PPPoE [1] is increasingly becoming the protocol of choice for
>>   provisioning residential and small business Internet service, this is
>>   having the undesirable effect of reducing the effective MTU for large
>>   segments of Internet users from 1500 octets to 1492 octets.
>>    
>>
>
>Protocol of choice or not, PPPoE has a number of serious problems,
>perhaps chief among them that it hasn't gone through any of the IETF
>review processes.  (Ignoring the obvious design flaws, such as the
>one-way assignment of session IDs.)
>
>I'm not sure that we should try too hard to publish extensions to
>something that is effectively a dead end.  If someone's interested, I
>suppose publishing it as yet another "Informational" RFC doesn't
>completely break the rules, but it does seem at least a bit
>misleading.
>
>  
>
>>   The reduced MTU can cause problems for any equipment or software that
>>   is configured with a static MTU, in particular if the expected or
>>   default value is 1500. In addition, widespread adoption of a lower
>>   MTU reduces the overall efficiency of the Internet.
>>    
>>
>
>I don't think "efficiency" of 1492 versus 1500 is noticable at all.
>The real issue is that Path MTU Discovery just doesn't work.  It
>doesn't work because there are huge numbers of horribly broken packet
>filters (firewalls) and NATs out there, and there's just nothing
>anyone can do about the problem.
>
>And it's yet another good reason why PPPoE is probably not a good
>idea.
>
>  
>
>>   Devices that are not capable of handling the extra 8 octets in their
>>   Ethernet Header SHOULD negotiate an MRU no larger than 1492. If no
>>   MRU has been specified by the receiving side, the sending side MAY
>>   assume that the receiving side is capable of handling the PPP default
>>   MRU of 1500. To ensure compatability with older equipment, if the
>>    
>>
>
>As above, I believe that breaks compatibility.  The default has to be
>1492.
>
>  
>
>>   sending side is assigning an MRU greater than 1492 to the receiving
>>   side, (either by default, or through negotiation), it is RECOMMENDED
>>   that the sending side send one or more MRU-sized Echo-Request packets
>>   once the session is opened, to test that the receiving side and any
>>   intermediate equipment can handle the MRU. If no Echo-Replies are
>>    
>>
>
>I think that a procedure like that is a *requirement*, not just a
>recommendation.  The problem is that there simply is no way for any
>PPPoE implementation to know whether the intermediate devices (which
>may include switches that add and remove VLAN tags) support an actual
>MTU of 1508.  There's just no way to know that what's being negotiated
>is at all reasonable.
>
>  
>
>>   received, the sending side MAY choose to repeat the test with
>>   Echo-Request packets of size 1492. If these packets receive replies,
>>   the sending side MAY choose to treat the receiver as if it had
>>   explicitly specified an MRU of 1492.
>>    
>>
>
>I think that's ambiguous.  It should probably restart LCP instead.
>
>  
>


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