> -----Original Message----- > From: James Carlson [mailto:james.d.carlson@xxxxxxx] > Sent: Monday, February 20, 2006 12:54 PM > To: Veera Tubati (vtubati) > Cc: Pekka Savola; pppext@xxxxxxxx; iesg@xxxxxxxx; ietf@xxxxxxxx > Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater > than1492 in PPPoE' to Informational RFC > > 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. 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. 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. > > -- > James Carlson, KISS Network <james.d.carlson@xxxxxxx> > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
