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

From: "Veera Tubati \(vtubati\)" <[email-masked]>
Date: Mon, 20 Feb 2006 11:40:46 -0800

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Monday, February 20, 2006 10:38 AM
> To: Veera Tubati (vtubati)
> Cc: [email-masked]; [email-masked]; 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-masked]>
> 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-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: James Carlson <[email-masked]>
Date: Mon, 20 Feb 2006 14:47:52 -0500

> states that (section 5.2) sending side wouldn't send packets bigger than

Either solution would be reasonable, I suppose.

> have any bearing on TCP connection which still thinks it can use higher

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.

> MTU) to hit this problem case.

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

-- 
James Carlson, KISS Network                    <[email-masked]>
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

---

From: Paul Jakma <[email-masked]>
Date: Mon, 20 Feb 2006 20:26:13 +0000 (GMT)

On Mon, 20 Feb 2006, James Carlson wrote:

> Isn't it always possible for the link to flap or for routes to 
> change such that you use different interfaces at different times?

And could happen somewhere in the 'middle' of the internet too, even 
if the PC<->ISP path stays perfectly stable.

> I don't see how this issue is any different.

Indeed.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Time to take stock.  Go home with some office supplies.