On Tue, Sep 19, 2017 at 4:42 AM, Harald Welte <lafo...@gnumonks.org> wrote: > Hi Tom, > > On Mon, Sep 18, 2017 at 05:38:55PM -0700, Tom Herbert wrote: >> Removes MTU handling in gtp_build_skb_ip4. This is non standard relative >> to how other tunneling protocols handle MTU. The model espoused is that >> the inner interface should set it's MTU to be less than the expected >> path MTU on the overlay network. Path MTU discovery is not typically >> used for modifying tunnel MTUs. > > The point of the kernel GTP module is to interoperate with existing > other GTP implementations and the practises established by cellular > operators when operating GTP in their networks. > > While what you describe (chose interface MTU to be less than the > expected path MTU) is generally best practise in the Linux IP/networking > world, this is not generally reflected in the cellular > universe. You see quite a bit of GTP fragmentation due to the fact > that the transport network simply has to deal with the MTU that has > been established via the control plane between SGSN and MS/UE, without > the GGSN even being part of that negotiation. > > Also, you may very well have one "gtp0" tunnel device at the GGSN, > but you are establishing individual GTP tunnels to dozesn to hundreds of > different SGSNs at operators all over the world. You cannot reliably > set the "gtp0" interface MTU to "the path MTU of the overlay network", > as the overlay network is in fact different for each of the SGSNs you're > talking to - and each may have a different path MTU. > > So unless I'm missing something, I would currently vote for staying with > the current code, which uses the path MTU to the specific destination IP > address (the SGSN). > Okay, I'll modify tnl_update_pmtu so we can call it from GTP and not have to replicate that function. I suspect VXLAN might also what this at some point.
Tom > Regards, > Harald > > -- > - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6)
