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

From: James Carlson <[email-masked]>
Date: Mon, 20 Feb 2006 15:53:46 -0500

Veera Tubati (vtubati) writes:
> > 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.

So ... we're worried about a BRAS that is unable to handle the load of
one extra packet for those 20K clients but that will perform
"acceptably" when those same 20K clients are all actively using their
links?

I don't quite understand, but it sounds to me like a design issue for
the BRAS and not a protocol issue.  If it wants, that machine could
sequence the link bring-up so that it spreads out the load, or it
could just use a more capable hardware platform.

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

I agree that consenting peers may do as they like, but it's not an
optimization that makes sense to me.

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

---

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

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Monday, February 20, 2006 12:18 PM
> To: Veera Tubati (vtubati)
> Cc: Pekka Savola; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater
> than1492 in PPPoE' to Informational RFC
> 
> > 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?"
> 

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

Veera