15

I've got an application that would benefit from larger Ethernet frames. (In theory, we could reduce the number of outbound packets by > 50%, maybe even 66%.)

I'm also in the process of specifying networking requirements with candidate hosting companies for a new installation of my application servers. It would be nice to, at a minimum, not restrict client connections from benefiting from Jumbo Frames.

But how realistic is this? Some general questions, assuming the segment of the network we can control is Jumbo Frame-friendly (switches are large MTUs capable, ICMP MTU path discovery allowed, etc.):

  • Is it realistic to send Jumbo Frames over the public Internet?
  • Is it inviting endless networking problems trying to support Jumbo Frames over the public Internet?
  • Are there any other concerns that I've not considered?
Stu Thompson
  • 3,339
  • 6
  • 30
  • 47

5 Answers5

11

The key here is that you can control your little segment of the network and enable large MTUs but you can't control the path your packets take over the internet and certainly can't control the configuration of the routers your packets will pass through. Most internet routers aren't configured above 1500 so you aren't going to have much luck with this solution. Worse, sometimes larger packets will actually get dropped by routers that don't support jumbo frames so I think you'd actually find things are worse if you try sending jumbo frames to the internet.

Jumbo frames are great on your internal network - especially for networks doing streaming or iSCSI.

icky3000
  • 4,718
  • 1
  • 20
  • 15
3
  1. Unless your view of the internet is from you via a single entity who will allow you to be extremely specific about this issue with and then on to some equally controllable end point then there's a >99.9% chance you traffic will not be transited 'intact' and maintain it's JF's. The reason is that JF's are an ethernet specification and not all of the internet is ethernet so they get disassembled, reassembled, transited then re-packetised.
  2. Problems - probably not, maybe on day one you may run into a problem or two but once it's up and working it should be fine.
  3. I would say that unless you have complete control of every part of the chain from server to client I'd be tempted to engineer my system considering the lowest, not highest, common denominators, i.e. get it working then tune, not the other way around.
Chopper3
  • 100,240
  • 9
  • 106
  • 238
  • 99.9% of the Internet is Ethernet and this doesn't assure jumbo frames are supported. – Marcelo Pacheco Dec 08 '20 at 05:49
  • 1
    erm....not so sure about that, when you consider that a lot of the end-user side of the internet is ADSL then saying it's 99% ethernet goes out of the window as that's ATM based. – Chopper3 Dec 08 '20 at 09:39
  • ADSL is dying quickly in Brazil. ISPs in the countryside have been rolling out fiber massively for nearly 5 years. And the big ISPs are being forced to migrate or loose all of their customers. 100 Mbps internet is becoming commonplace, even in 100k people cities. – Marcelo Pacheco Dec 08 '20 at 09:56
  • Same here in the UK, but we're still about 85% ADSL for now – Chopper3 Dec 08 '20 at 17:29
  • Let me add that my expectation would be that the Internet backbone supports jumbo frames, not all end users. And hosting providers. – Marcelo Pacheco Dec 09 '20 at 04:00
3

A lot of the tertiary education networks (AARNET, JANET, Internet2) have end to end enabled jumbo frames on their networks. If you are serving people on those networks I would suggest it is worthwhile.

Haakon
  • 1,305
  • 7
  • 11
2

As others have said above the answer is currently no.

Also consider the MTU of your providers uplink, unless that supports Jumbo frames, then you are out of luck before you start.

Dave Cheney
  • 18,307
  • 7
  • 48
  • 56
0

My experience is that Jumbo Frames are usually constrained to a dedicated link between an application server and its database server. The number of types of incompatibility possibilities on anything more complex is mind-boggling.

kmarsh
  • 3,103
  • 15
  • 22