Kitz Forum
Internet => General Internet => Topic started by: Weaver on September 20, 2016, 08:14:13 PM
-
I wonder if there will ever be an opportunity to start to replace the 1500 byte MRU / MTU across the internet. There are of course some jumbo LANs with ~9000 byte frame sizes allowed.
If we were ever to start making the change what would the next step up be? Up to 9k? To just under 64k? More? (I have this vague recollection that some protocols might start to break if we get near to 64k, because of field size limits, can't remember though.)
It's obviously a good thing if routers and switches have to process fewer packets per second. And ram is cheaper. On the other hand, long queuing delays are very bad, so sane queuing policy and good design would be a must, but then that's just another way of saying don't design things badly.
Of course, some use-cases would possibly want to keep packet sizes down because of real-time considerations. (Revisit the considerations behind the design of ATM.)
Somehow I can't see that 1500 bytes is going to be an ideal choice for decades to come, so perhaps now would be the time to start, saying that all new good Internet core routers should handle x byte packets. Testing might be a problem, as getting complete joined up end-to-end paths would be needed before experience could be gained from large-scale real-world field testing outside big labs with controlled kit.
-
even after the standardisation of 1500 byte mtu there is still issues with some routers and endpoints needing smaller sizes.
jumbo frames exists but like ipv6 it will take time for things to progress.
-
Server and storage guys used to make a big deal about jumbo frame support, presumably by comparison with Fibre Channel with its 16K frame size. However in reality may data centres using IP storage (iSCSI or NFS) tend not to bother. It can cause issues, for example we diagnosed a problem with Lync conferencing over the WAN (everything's a network problem) and found that the stupid Lync server was sending out it's media in jumbo frames with don't fragment set.
-
Assuming enough support is found, hypothetically; how would we make the change? Got to start somewhere, where would that be?
Another question which is not the same thing: I read something somewhere about BT systems being capable of handling 1600 byte long xPDUs ( perhaps L2-PDUs ). Very good thing; not in the range proposed here of course, but extremely helpful. Does this ring any bells?
-
The core routers already support jumbo frames and carry bigger PDUs than 1500 bytes as on top of Ethernet there are 32 bit MPLS headers.
The 1500 bytes is going nowhere. A fair amount of traffic uses less that 1500 bytes and links are so large overheads are virtually inconsequential.
Jumbo is only used for data replication, usually across long distances at high bandwidth, with private lines with 0% loss SLAs and that's reasonable.
For now the 1500 bytes remains a good compromise between minimal overheads and the diminishing returns as data needs retransmission over unreliable networks.
-
Thanks Carl. How much of the path would you say is MTU > 1600 bytes ?
-
Hard to say as it's far from uncommon now for routers to implement jumbo frame support automatically when an oversized frame arrives.
Cisco's ASR 9000 series for instance do this - they increment a counter for an oversized frame if it arrives on an interface at default MTU and send it across regardless, fragmenting it if necessary for the next hop.
-
But they can handle oversized frames if the next hop can?
I don’t understand the counter; assuming it’s concerned with the fragmentation ? Seems a strange thing to do. I would have kept an amount_still_to_be_sent counter
-
The counter is nothing to do with handling the actual frame it's just to indicate that an oversized frame arrived.
Usually you wouldn't expect to see those on core network as the edge, either customer or provider, should be cutting things down to size.
Points to a configuration mismatch. Noteworthy.
You might find Link Layer Discovery Protocol / LLDP / 802.1AB an interesting read.
-
Got it, thanks. Will enjoy reading matter.
-
You might find Link Layer Discovery Protocol / LLDP / 802.1AB an interesting read.
b*cat takes note and downloads a copy of the document.
-
b*cat takes note and downloads a copy of the document.
Can you translate it for us dumb humans? I noticed my main switch uses LLDP but haven't a clue what any of it means.
-
Can you translate it for us dumb humans?
The document I found and downloaded (802.1AB Overview Link Layer Discovery Protocol - IEEE 802 (http://www.ieee802.org/3/frame_study/0409/blatherwick_1_0409.pdf)) turned out to be a set of slides from a presentation to the IEEE 802.3 Frame Expansion Study Group, at Ottawa, on Sept 30, 2004. The Wikipedia page, Link Layer Discovery Protocol (https://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol), is obviously more current.
Essentially, it is a unified method to discover accessible devices at the link layer (of the OSI seven layer model (https://en.wikipedia.org/wiki/OSI_model)) designed to supersede various proprietary protocols.
I think CarlT would be the best person to explain it in any detail.
-
My HP switch has support for LLDP and LLDP-MED.