ietf
[Top] [All Lists]

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

2006-02-21 13:36:34


-----Original Message-----
From: James Carlson [mailto:james(_dot_)d(_dot_)carlson(_at_)sun(_dot_)com]
Sent: Monday, February 20, 2006 12:18 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:
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
<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