Hi Jesse, Thanks for responding. I also found http://discuss.openvswitch.narkive.com/WvgqV9fj/ovs-discuss-tunnel-path-mtu-discovery-deprecated-in-1-9-and-what-t-the-substitution about Path MTU discovery, 3 years ago. It seems like the topic is being discussed over and over, without ever getting solved.
With this patch, OVS wouldn't apply MSS clamping unless configured to do so. It would leave the decision whether this is a good idea or not with the users of OpenVSwitch, for a particular configuration / use case. Modifying users' packets is what OVS does, based on its configuration. Does it really matter whether it is due to an action, or a configuration option ( hard-coded action if you will )? Regards, Jeroen On Tue, Jun 21, 2016 at 4:29 PM, Jesse Gross <je...@kernel.org> wrote: > On Mon, Jun 20, 2016 at 8:40 AM, Jeroen van Bemmel <jvb...@gmail.com> wrote: >> Hello, >> >> When using VXLAN over Internet connections, Openvswitch TCP >> performance is currently limited due to IP fragmentation: The Internet >> MTU is (at most) 1500 bytes, and the typical TCP MSS value of 1460 >> bytes used by clients becomes 1460+40+50 VXLAN = 1550 bytes. >> >> The attached patch addresses this issue, by modifying the TCP MSS >> option in TCP SYN and SYN+ACK packets to account for VXLAN overhead. >> It only applies to packets sent to or from VXLAN ports ( though could >> be applied to other tunnel types as well ). >> >> I realize there are many things wrong about the patch, it's not >> properly formatted and we would want the feature to be configurable ( >> per port perhaps ). But before I go ahead and polish things up, I'd >> like to collect some feedback on the general approach and desirability >> of this feature. >> >> I built another patch to create a custom tcp-mss-rewrite Openflow >> action, but I think for many applications this would complicate things >> as flows have to be explicitly programmed. By making it part of the >> standard output action, it can simply be dropped in and existing >> applications can take advantage of the feature without modifications >> to their code > > I think you might have forgotten to attach the patch or it got clipped > off by a mail server somewhere. > > In general, I think automatically clamping MSS for output actions > doesn't really seem like a good idea. Even if it only applied to > tunnel ports, OVS shouldn't change users' packets by itself. > > There was a thread about different ways to deal with MTU and tunnels. > It didn't really lead to a conclusion yet but I think figuring out a > way to make it work is the best way to solve this problem. > http://openvswitch.org/pipermail/discuss/2016-May/021151.html _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
