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 16:16:13 -0500

Veera Tubati (vtubati) writes:
> > 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.
> 
> It is clear that is not an issue with the protocol, but seems there are
> practical reasons which pushed for the birth of this draft.

That seems unrelated to the potential performance issue I thought we
were discussing.

In any event, the draft authors wanted explicit signaling because of
the behavior of the existing PPPoE implementations.  There's little
way to be _sure_ you're talking to a new one without checking.  (I
think a boolean would be sufficient for that, but I see no problem
with having an integer value instead.)

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

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

---

From: James Carlson <[email-masked]>
Date: Mon, 20 Feb 2006 16:16:13 -0500

---

From: James Carlson <[email-masked]>
Date: Mon, 20 Feb 2006 16:16:13 -0500

---

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

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Monday, February 20, 2006 12:54 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
> 
> > > 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?
> 

Veera

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