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

> -----Original Message-----
> From: James Carlson [mailto:[email protected]]
> Sent: Monday, February 20, 2006 12:18 PM
> To: Veera Tubati (vtubati)
> Cc: Pekka Savola; [email protected]; [email protected]; [email protected]
> Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater
> than1492 in PPPoE' to Informational RFC
> 
> Veera Tubati (vtubati) writes:
> > That can be done but then that means for PPPoE sessions to go beyond
> > 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.

Correct, but it could be in the order of 20k or more sessions trying to
come up at once after the outage of a BRAS box. For the broken clients
asking for 1500, it is more overhead to timeout and retry something
else. Whatever can be avoided reasonably is a bonus.

> 
> Why is that a cost worth optimizing -- especially at the risk of
> losing correctness?
> 
> > 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.
> 
> 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.

May be there would be cases where ISP is sure that their underlying
network and clients support 1500 MRU indeed...

Veera

> 
> --
> James Carlson, KISS Network
<[email protected]>
> 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 protected]
https://www1.ietf.org/mailman/listinfo/pppext