That's an unusual question, but probably not a useful one. Even if you configure your own infrastructure with jumbo frame support, and your provider does the same, chances are that the huge majority of end-users will not be able to receive jumbo frames. Transit circuits, peering exchanges, and end-customer interfaces are going to have smaller MTU sizes which will simply result in TCP PMTUd selecting an MSS that is substantially smaller than the frame size your wire supports.
If you disable PMTUd and simply transit jumbo frames, and TCP segments, with don't-fragment unset, you will just cause fragmentation somewhere in your upstream path; and this can harm performance for end-users when, for example, a fragment is discarded and whole IP packet cannot be reassembled at the far-end. The entire TCP segment must be retransmitted. Supporting jumbo frames can be a big headache for virtually no gain.
What is your application? Have you logged advertised TCP MSS value on sessions from your user base to determine if jumbo frames can be a benefit even under ideal transit network circumstance?
Well I believe it to be very useful for me. Since the application is ftp, it matters not what the MTU is at the end point. I want to get data off my box/boxes as quickly and efficiently as possible. Since PCs do not have ASIC chips that do fragmentation in hardware, I want the upstream routers to do this. I can easily save 30-50% overhead on my box/boxes with high one way traffic (HTTP, FTP, etc) using jumbo frames.
I suspect you'll find that most hosting companies with knowledgable network operations staff will be able to support mini-jumbo frames with relative ease; but it doesn't sound like that would give you the performance benefit you're looking for. Getting into the 9KB range may be challenging depending on the hardware they use to terminate your ethernet circuit.
I've evaluated this on some of my clients' networks, and those I've looked at in detail could not accomodate your need unless you were to commit enough traffic to warrant landing your circuit on a rather expensive layer 3 interface. I suspect you'll find that to be the case with most vendors that you contact.
I understand your desire to both reduce the number of transmitted segments and ACKs that must be processed by your server(s); however I can't imagine this being such a large benefit that it would motivate you to choose certain service providers based on their ability to provide a jumbo-capable handoff.
Have you considered offloading the fragmentation duties onto another box of your own, for example an additional PC, layer 3 switch, or router that can bear your traffic? I don't see this as being a cost/performance win, either; I'm just throwing an option out.
It's doable. But Jeff is correct, you're going to get a port charge for this simply because your drop would be provision directly from the router or the core. Both tends to have expensive per port cost.
http://Ethr.email@example.com West Coast AT&T / Level3 / Savvis Bandwidth, Colocation, Dedicated Server, Managed IP Service, Hardware Load Balancing Service, Transport Service, 365 Main St, SFO / 200 Paul Ave, SFO / PAIX, PAO / Market Post Tower, 55 S. Market, SJC / 11 Great Oaks, Equinix, SJC