-----Original Message-----
From: James Carlson [mailto:james(_dot_)d(_dot_)carlson(_at_)sun(_dot_)com]
Sent: Monday, February 20, 2006 12:54 PM
To: Veera Tubati (vtubati)
Cc: Pekka Savola; pppext(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
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(_dot_)d(_dot_)carlson(_at_)sun(_dot_)com>
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf