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

Veera Tubati (vtubati) writes:
> > If the MTU negotiated at LCP time later turns out to be a problem,
> > you're going to need to restart LCP anyway, and that will tear down
> > IPCP.  So how does waiting help?  At best it avoids a small bounce (IP
> > goes up briefly, then down and back up again) in an unusual error
> > case.
> 
> 1. Draft doesn't imply that LCP would restart in this case. It just
> states that (section 5.2) sending side wouldn't send packets bigger than
> 1492.

Either solution would be reasonable, I suppose.

> 2. Even if IPCP is restarted it is not going help the cases of PPPoE
> session starting from a CPE or DSLAM (fig 2 and 3 respectively from the
> draft) while TCP would be from the end PC. Bouncing IPCP wouldn't really
> have any bearing on TCP connection which still thinks it can use higher
> MTU. 

I don't see how that's really PPP's problem.  If the TCP/IP
implementation you're using can't manage to deal with an IP link going
down and coming back up with a different MTU, then that's a flaw in
the TCP/IP implementation, not PPP.

Isn't it always possible for the link to flap or for routes to change
such that you use different interfaces at different times?  I don't
see how this issue is any different.

It's a quality of implementation issue, not a protocol issue.

> But agreed that TCP from PC has to come up in a narrow time window
> (before test could detect a problem with negotiated MRU and adjust the
> MTU) to hit this problem case.

... and be on a system with a flawed TCP implementation as well.

-- 
James Carlson, KISS Network                    <[email protected]>
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 protected]
https://www1.ietf.org/mailman/listinfo/pppext