<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 January 2016 at 11:27, Adam Lawson <span dir="ltr"><<a href="mailto:alawson@aqorn.com" target="_blank">alawson@aqorn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">For the sake of over-simplification, is there ever a reason to NOT enable jumbo frames in a cloud/SDN context where most of the traffic is between virtual elements that all support it? I understand that some switches do not support it and traffic form the web doesn't support it either but besides that, seems like a default "jumboframes = 1" concept would work just fine to me.</div></blockquote><div><br><div><div>Offhand:<br><br></div>1. you don't want the latency increase that comes with 9000 byte packets, even if it's tiny (bearing in mind that in a link shared between tenants it affects everyone when one packet holds the line for 6 times longer)<br></div><div>2. not every switch in the world is going to (a) be configurable or (b) pass 9000 byte packets<br></div><div>3.
not every VM has a configurable MTU that you can set on boot, or 
supports jumbo frames, and someone somewhere will try and run one of 
those VMs<br></div><div>4. when you're using provider networks, not 
every device attached to the cloud has a 9000 MTU (and this one's 
interesting, in fact, because it points to the other element the MTU 
spec was addressing, that *not all networks, even in Neutron, will have 
the same MTU*).  <br>5. similarly, if you have an external network in 
Openstack, and you're using VXLAN, the MTU of the external network is almost certainly 50
 bytes bigger than that of the inside of the VXLAN overlays, so no one 
number can ever be right for every network in Neutron.<br></div><div><br></div>Also,
I say 9000, but why is 9000 even the right number?  We need a number... and 'jumbo' is not a 
number.  I know devices that will let you transmit 9200 byte packets.  
Conversely, if the native L2 is 9000 bytes, then the MTU in a Neutron 
virtual network is less than 9000 - so what MTU do you want to offer 
your applications?  If your apps don't care, why not tell them what MTU 
they're getting (e.g. 1450) and be done with it?  (Memory says that the old problem with that was that github had problems with PMTUD in that circumstance, but I don't know if that's still true, and even if it is it's not technically our problem.)<br><br></div><div>Per the spec, I would like to see us do the remaining fixes to make that work as intended - largely 'tell the VMs what they're getting' - and then, as others have said, lay out simple options for deployments, be they jumbo frame or otherwise.<br><br>If you're seeing MTU related problems at this point, can you file bugs on them and/or report back the bugs here, so that we can see what we're actually facing?<br></div>-- <br></div><div class="gmail_quote">Ian.<br></div></div></div>