Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC

From: "Veera Tubati \(vtubati\)" <[email-masked]>
Date: Mon, 20 Feb 2006 12:07:34 -0800

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Monday, February 20, 2006 10:50 AM
> To: Pekka Savola
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater
> than1492 in PPPoE' to Informational RFC
> 
> Pekka Savola writes:
> > I guess the problem I was having here is that I didn't understand
why
> > a PPPoE MTU options would be useful (still don't).  After all, if
both
> > PPP endpoins would signal MRU = 2000 (for example), then PPPoE could
> > just use that with no need for an extra option?  Looking back at the
> > archives, it appears others have had related concerns, so I guess
this
> > is beating a dead horse..
> 
> I think it is.  What's really needed is some end-to-end mechanism
> within 802 itself for making sure that the MTU on the path is
> correct.  That mechanism doesn't really exist.
> 
> There are several problems here.  First of all, there are several
> PPPoE implementations that will assume a fixed limit of 1492 (based on
> requirements of the 802 the standards), no matter what PPP attempts to
> negotiate.  So merely having the LCP MRU option show something larger
> won't help -- the peer already "knows" that the path can't possibly be
> that wide.
> 
> Now, it'd be reasonable to have LCP negotiate an MRU > 1492, and then
> use LCP Echo-Request (in parallel with IPCP start-up) to verify that
> the path really supports packets that large.  If it doesn't, then
> restart LCP and negotiate a fixed 1492.  That wouldn't require any
> protocol changes at all.

That can be done but then that means for PPPoE sessions to go beyond
1492 BRAS always have to incur this cost of verification; as BRAS may
not be able to turn off that verification selectively either as it
wouldn't be certain which clients really are asking for 1500 MRU (due to
underlying network really supporting it) or which are asking 1500 MRU
due to their config/implementation being broken. Seems fixing these
broken clients would be a much overhead for Service provider.

Veera 

> 
> I think something like that is what you're suggesting.  It seems
> reasonable to me, except that I think the draft authors wanted
> explicit signaling between the peers to enable the new mode of
> operation.
> 
> --
> James Carlson, KISS Network
<[email-masked]>
> Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442
2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442
1677
> 
> _______________________________________________
> 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: James Carlson <[email-masked]>
Date: Mon, 20 Feb 2006 15:18:26 -0500

Veera Tubati (vtubati) writes:
> 1492 BRAS always have to incur this cost of verification;

"Cost?"

We're talking about a single MTU-sized packet transmitted and one
received on an Ethernet link.

Why is that a cost worth optimizing -- especially at the risk of
losing correctness?

> as BRAS may

Right, I think that may well be one of the concerns: existing old
implementations that use an incorrect MTU would end up causing the
peer to probe and time out.

I think it'd still be possible to do something reasonable here without
the extra flag, but it's probably not worth the effort.

However, that doesn't mean that turning off the check for new
implementations with this new feature is a good idea.  I think it's a
hazard and I see no benefit.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677