[{"id":1770926,"web_url":"http://patchwork.ozlabs.org/comment/1770926/","msgid":"<20170919114205.z2txj6rwo2row7u4@nataraja>","list_archive_url":null,"date":"2017-09-19T11:42:05","subject":"Re: [PATCH net-next 05/14] gtp: Remove special mtu handling","submitter":{"id":931,"url":"http://patchwork.ozlabs.org/api/people/931/","name":"Harald Welte","email":"laforge@gnumonks.org"},"content":"Hi Tom,\n\nOn Mon, Sep 18, 2017 at 05:38:55PM -0700, Tom Herbert wrote:\n> Removes MTU handling in gtp_build_skb_ip4. This is non standard relative\n> to how other tunneling protocols handle MTU. The model espoused is that\n> the inner interface should set it's MTU to be less than the expected\n> path MTU on the overlay network. Path MTU discovery is not typically\n> used for modifying tunnel MTUs.\n\nThe point of the kernel GTP module is to interoperate with existing\nother GTP implementations and the practises established by cellular\noperators when operating GTP in their networks.\n\nWhile what you describe (chose interface MTU to be less than the\nexpected path MTU) is generally best practise in the Linux IP/networking\nworld, this is not generally reflected in the cellular\nuniverse. You see quite a bit of GTP fragmentation due to the fact\nthat the transport network simply has to deal with the MTU that has\nbeen established via the control plane between SGSN and MS/UE, without\nthe GGSN even being part of that negotiation.\n\nAlso, you may very well have one \"gtp0\" tunnel device at the GGSN,\nbut you are establishing individual GTP tunnels to dozesn to hundreds of\ndifferent SGSNs at operators all over the world. You cannot reliably\nset the \"gtp0\" interface MTU to \"the path MTU of the overlay network\",\nas the overlay network is in fact different for each of the SGSNs you're\ntalking to - and each may have a different path MTU.\n\nSo unless I'm missing something, I would currently vote for staying with\nthe current code, which uses the path MTU to the specific destination IP\naddress (the SGSN).\n\nRegards,\n\tHarald","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxMGP739Nz9s7c\n\tfor ;\n\tTue, 19 Sep 2017 22:13:17 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751735AbdISMNP (ORCPT );\n\tTue, 19 Sep 2017 08:13:15 -0400","from ganesha.gnumonks.org ([213.95.27.120]:45328 \"EHLO\n\tganesha.gnumonks.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751480AbdISMNN (ORCPT\n\t); Tue, 19 Sep 2017 08:13:13 -0400","from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.84_2)\n\t(envelope-from )\n\tid 1duHOm-0001IU-Jz; Tue, 19 Sep 2017 14:13:08 +0200","from laforge by localhost.localdomain with local (Exim 4.89)\n\t(envelope-from )\n\tid 1duGuj-0006XZ-7u; Tue, 19 Sep 2017 19:42:05 +0800"],"Date":"Tue, 19 Sep 2017 19:42:05 +0800","From":"Harald Welte ","To":"Tom Herbert ","Cc":"davem@davemloft.net, netdev@vger.kernel.org, pablo@netfilter.org,\n\trohit@quantonium.net","Subject":"Re: [PATCH net-next 05/14] gtp: Remove special mtu handling","Message-ID":"<20170919114205.z2txj6rwo2row7u4@nataraja>","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-6-tom@quantonium.net>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170919003904.5124-6-tom@quantonium.net>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1771268,"web_url":"http://patchwork.ozlabs.org/comment/1771268/","msgid":"","list_archive_url":null,"date":"2017-09-19T18:12:44","subject":"Re: [PATCH net-next 05/14] gtp: Remove special mtu handling","submitter":{"id":65986,"url":"http://patchwork.ozlabs.org/api/people/65986/","name":"Tom Herbert","email":"tom@herbertland.com"},"content":"On Tue, Sep 19, 2017 at 4:42 AM, Harald Welte wrote:\n> Hi Tom,\n>\n> On Mon, Sep 18, 2017 at 05:38:55PM -0700, Tom Herbert wrote:\n>> Removes MTU handling in gtp_build_skb_ip4. This is non standard relative\n>> to how other tunneling protocols handle MTU. The model espoused is that\n>> the inner interface should set it's MTU to be less than the expected\n>> path MTU on the overlay network. Path MTU discovery is not typically\n>> used for modifying tunnel MTUs.\n>\n> The point of the kernel GTP module is to interoperate with existing\n> other GTP implementations and the practises established by cellular\n> operators when operating GTP in their networks.\n>\n> While what you describe (chose interface MTU to be less than the\n> expected path MTU) is generally best practise in the Linux IP/networking\n> world, this is not generally reflected in the cellular\n> universe. You see quite a bit of GTP fragmentation due to the fact\n> that the transport network simply has to deal with the MTU that has\n> been established via the control plane between SGSN and MS/UE, without\n> the GGSN even being part of that negotiation.\n>\n> Also, you may very well have one \"gtp0\" tunnel device at the GGSN,\n> but you are establishing individual GTP tunnels to dozesn to hundreds of\n> different SGSNs at operators all over the world. You cannot reliably\n> set the \"gtp0\" interface MTU to \"the path MTU of the overlay network\",\n> as the overlay network is in fact different for each of the SGSNs you're\n> talking to - and each may have a different path MTU.\n>\n> So unless I'm missing something, I would currently vote for staying with\n> the current code, which uses the path MTU to the specific destination IP\n> address (the SGSN).\n>\nOkay, I'll modify tnl_update_pmtu so we can call it from GTP and not\nhave to replicate that function. I suspect VXLAN might also what this\nat some point.\n\nTom\n\n> Regards,\n> Harald\n>\n> --\n> - Harald Welte http://laforge.gnumonks.org/\n> ============================================================================\n> \"Privacy in residential applications is a desirable marketing option.\"\n> (ETSI EN 300 175-7 Ch. A6)","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=herbertland-com.20150623.gappssmtp.com\n\theader.i=@herbertland-com.20150623.gappssmtp.com\n\theader.b=\"alWGgtgC\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxWFG1W52z9s82\n\tfor ;\n\tWed, 20 Sep 2017 04:12:50 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751425AbdISSMr (ORCPT );\n\tTue, 19 Sep 2017 14:12:47 -0400","from mail-qt0-f169.google.com ([209.85.216.169]:46568 \"EHLO\n\tmail-qt0-f169.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751040AbdISSMq (ORCPT\n\t); Tue, 19 Sep 2017 14:12:46 -0400","by mail-qt0-f169.google.com with SMTP id s18so499037qta.3\n\tfor ; Tue, 19 Sep 2017 11:12:45 -0700 (PDT)","by 10.237.61.196 with HTTP; Tue, 19 Sep 2017 11:12:44 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=herbertland-com.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=kXXBJ2QqfgC1Tw5x7GX+iN+fGikkQcgdlMJ8KPZsc/s=;\n\tb=alWGgtgCX8P1vgNayaEmDn0XeQ4NS5mcxcMyiKsUv6WSTbQa5d1qfortM4vKfglIbI\n\tm4ZkfzS0RnwFU3JZ++02cWufIa7/P/QwV2Mexg0h0bs9nhe9EIrHLOhmLsamqbajnIBy\n\t7gstnDMbTtwCeh45Rpuox0hDcPudVj7JwaEMMrvOtWK4DqFUw9QvWPb3I7eWfOdby67+\n\taOC2wGZNFGPuZpVbYGH4goHFdur+1Kh46lvG3aZPLBy6IVHeI6r9PnIYnvKHwRGFLltd\n\t4daZHY7Jf4Q/i5w1udqWstRJkwrmDy3dzwa8LUb2IzDz4nWsSXBgwuJjbxqmPhQDunRc\n\ty/tA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=kXXBJ2QqfgC1Tw5x7GX+iN+fGikkQcgdlMJ8KPZsc/s=;\n\tb=tT4gWmiIFFFPn5cnUxUkHeI0x1zH8yZEWrlYSAckGiaY3g5R8zKFyNNxyjCl+jR9Wk\n\t8arZJerblO02TlGYymFTlqSYj/vAizduyS5pDyA3CXCYa/vyGC59YI63wTvq8Kil+6cm\n\tCdZdV9LSo6kmrjGfVyNSKHAGxAjZXp4BS46N2kbyisbHbfj55zJyUoqYFfkbNicEdeeV\n\tUsyWb/5ms4SEU1FwRTbqfRKRGjxZf90OiykbT7iLNSWIVfUL/IKb+17naVZBasjsjB3l\n\tXN5Z9Mdsu4sm+eAGRNyMUmbf++jZlEAN10BmH0/bzGxFsBS6h0yOz44Oo50VjX8ZgZKN\n\tSagA==","X-Gm-Message-State":"AHPjjUgd3L8rQjduhwUk25GBKyYpEFkiWJ0pRZwGorIOkLvU2rErHTgW\n\t6FboE7jpiYAXIyboawehQEyWUi5N+92HFubdlVJYGg==","X-Google-Smtp-Source":"AOwi7QC7UWho3gyAuD4tKcMgSLhH2iqQ9b7JRS1EolEIeUmlAQyiXc9O5GQx3oJ6L1DkaFkwwLjl598A2DERRWDhys0=","X-Received":"by 10.237.62.206 with SMTP id o14mr3558033qtf.286.1505844765171; \n\tTue, 19 Sep 2017 11:12:45 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170919114205.z2txj6rwo2row7u4@nataraja>","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-6-tom@quantonium.net>\n\t<20170919114205.z2txj6rwo2row7u4@nataraja>","From":"Tom Herbert ","Date":"Tue, 19 Sep 2017 11:12:44 -0700","Message-ID":"","Subject":"Re: [PATCH net-next 05/14] gtp: Remove special mtu handling","To":"Harald Welte ","Cc":"Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tRohit Seth ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]