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

> -----Original Message-----
> From: James Carlson [mailto:[email protected]]
> Sent: Monday, February 20, 2006 11:48 AM
> To: Veera Tubati (vtubati)
> Cc: [email protected]; [email protected]; Pekka Savola
> Subject: RE: [Pppext] 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.

That is correct but it seems ICMP error messages are filtered out (for
other reasons) on these networks and sending TCP end point is never
going to know that the packets it sent out with DF bit ON are not
reaching the peer. 

Reduced MTU of 1492 from PPPoE peer probably is more likely to cause
pain compared to possibility of MTU changes with route flaps likely to
become a bottle neck I guess...

I don't mean it is a problem with PPP but since this draft is defining a
mechanism for auto detection of problem with negotiated MRU already, I
was wondering if it has to be little more robust in the guidelines.

Veera

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