Subject: AW: AW: [L2tpext] fragmentation and MRU setting in L2TPv2 scenari os

From: [email-masked]
Date: Fri, 4 Apr 2003 11:39:42 +0100

Archie,

one thing puzzles me a bit in Your answer. You are
talking about negotiating a MTU value with the PPP
peer LARGER than 1500, while I am considering to propose
a MRU value (LNS) respectively MTU value (peer) for the
PPP connection SMALLER than 1500 (=equal to the maximum
unfragmented packet size in the pipe).
While I'm quite sure, that it would amend performance if
peer agrees on such a smaller value for the PPP link, I 
wonder whether it might make the PMTU problem worse for 
large packets from the server side.

best regards

Andreas

> > The question is now whether it makes sense to adapt the settings
> > of the MRU on the LNS and/or LAC (used as proposal for PPP 
> negotiation) 
> > to the maximum unfragmented packet size. Or are there any caveats
> > or side effects when doing this?
> 
> There are two levels at which IP fragmentation can happen, on the
> inner IP packet and on the outer IP packet. Outer packet fragments
> are a potential performance hit but otherwise not a problem. But
> if the inner IP packet must be fragmented - because you're not
> doing multi-link and your MTU for the L2TP link is too small for
> the original packet plus overhead - then your L2TP router is
> required to fragment the IP packet or send back an ICMP "must
> fragment" response if DF is set.
> 

> -----Ursprüngliche Nachricht-----
> Von: Archie Cobbs [mailto:[email-masked]]
> Gesendet am: Mittwoch, 2. April 2003 18:34
> An: Waibel, Andreas
> Cc: [email-masked]
> Betreff: Re: AW: [L2tpext] fragmentation and MRU setting in L2TPv2
> scenarios
> 
> [email-masked] wrote:
> >>The DF flag is set as a normal part of TCP's path-MTU
> >>discovery process:
> > 
> > sure, but I thought it should not be set in any normal
> > application data packet, once the path is discovered
> > or if PMTU was not enabled at all.
> 
> That's true.. although this falls under "what normally happens"
> rather than "what is required". E.g., there's nothing that
> says that a host can't initiate another PMTU discovery
> every 3 minutes if it wants to.
> 
> >>If peer A's MRU is < peer B's MTU, then there is a bug
> >>in somebody's PPP stack, as PPP negotiation should never
> >>allow this to happen.
> > 
> > The negotiated MRU/MTU value agreed on by both sides could 
> > still be larger than the actual maximum packet size for 
> > unfragmented transport over the wire. My interpretation of 
> > the PPP logs I have seen is that negotiation usally only depends 
> > on the (manual) settings on both sides. The actual maximum 
> > unfragmented packet size in the L2TP pipe may differ from 
> > the negotiated value.
> 
> The problem is that you don't control your PPP MTU, the peer
> does, and the peer is allowed to reject any values greater
> than 1500 bytes if it wants to. So the local configuration
> only sets an upper limit, not a lower limit in effect.
> 
> > The question is now whether it makes sense to adapt the settings
> > of the MRU on the LNS and/or LAC (used as proposal for PPP 
> negotiation) 
> > to the maximum unfragmented packet size. Or are there any caveats
> > or side effects when doing this?
> 
> There are two levels at which IP fragmentation can happen, on the
> inner IP packet and on the outer IP packet. Outer packet fragments
> are a potential performance hit but otherwise not a problem. But
> if the inner IP packet must be fragmented - because you're not
> doing multi-link and your MTU for the L2TP link is too small for
> the original packet plus overhead - then your L2TP router is
> required to fragment the IP packet or send back an ICMP "must
> fragment" response if DF is set.
> 
> You could avoid "inner" IP fragmentation if your L2TP link MTU
> were large enough, but your MTU setting is at the mercy of the
> remote PPP peer, because it is allowed to reject anything larger
> than 1500 bytes (and typically the inner IP packet is up to 1500
> bytes because it came from an Ethernet port). So you can't avoid
> this possibility in general.
> 
> If you're talking about a UNIX type device, then you would normally
> configure the L2TP interface to have an MTU of 1460 (or whatever)
> so that the kernel handles the fragmentation and ICMP stuff for you.
> 
> With multi-link PPP, inner IP fragmentation is no longer necessary
> as you can fragment at the PPP frame level instead.
> 
> So in summary:
> 
> - You must be prepared to fragment and/or send ICMP "must fragment"
>    packets (don't forget to decrement TTL's too)
> - Life gets easier if you enable multi-link PPP (even with just
>    one link)
> - Life gets easier if you can get the peer to accept a large
>    enough MTU for the L2TP link, but don't count on it.
> 
> FYI, WinXP is "friendlier" than earlier versions of Windows
> on these points...
> 
> > I understand that an application using PMTU sends 
> periodically large 
> > packets with the DF bit set. However I'm not sure, whether 
> these testing
> > packets are already normal data packets or just ICMP trials BEFORE
> > actually sending data. One way or another I understand now, that
> > the problem only happens if the application has PMTU enabled and 
> > does not have a timeout mechanism as described in RFC 2923
> > 
> >    How to fix
> >       TCP should notice that the connection is timing out.  After
> >       several timeouts, TCP should attempt to send smaller packets,
> >       perhaps turning off the DF flag for each packet.  If this
> >       succeeds, it should continue to turn off PMTUD for 
> the connection
> >       for some reasonable period of time, after which it 
> should probe
> >       again to try to determine if the path has changed.
> 
> You want to avoid having the application timeout.. it's much better to
> have all routers able to send ICMP "need fragmentation" packets and
> all intermediate firewalls not block these packets.
> 
> Hope this helps.
> 
> -Archie
> 
> ______________________________________________________________
> ____________
> Archie Cobbs     *     Precision I/O      *     
http://www.precisionio.com
_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: [email-masked]
Date: Fri, 4 Apr 2003 11:39:42 +0100

Archie,

best regards

Andreas