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 10:38 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:
> > I wonder if draft should state its position about IPCP start while
> > MRU test is enabled.
> >
> > I would think IPCP start should be delayed (if this verification
option
> > is enabled) till verification is finished and BRAS decides on MTU to
be
> > used. Else, if there is a TCP session coming in soon after IPCP is
up
> > and if verification process reduces the MTU later down to 1492 that
TCP
> > session would be using a wrong MTU and would have connectivity
problems.
> 
> I don't see how that'd be helpful.
> 
> 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.

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

Veera

> 
> And it's something that could be handled in a decent implementation by
> keeping track of the MAC address of the peer and remember the MTU
> limit.
> 
> --
> 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