Ethernet History Deepdive – Why Do We Have Different Frame Types?
1–10 of 86 posts
Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?
#2Ironically, this version of the header published in 1980 is what we still use to this day.
IMHO Ethernet is one of the of great examples of backwards compatibility in the computing world. Even the wireless standards present frames to the upper layers like they're Ethernet. It's also a counterexample to the bureaucracy of standards bodies --- the standard that actually became widely used was the one that got released first. The other example that comes to mind is OSI vs DoD(TCP/IP).
Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?
#3Ironically, this version of the header published in 1980 is what we still use to this day. IMHO Ethernet is one of the of great examples of backwards compatibility in the computing world. Even the wireless standards present frames to the upper layers like they're Ethernet. It's also a counterexample to the bureaucracy of standards bodies --- the standard that actually became widely used was the one that got released…
OSI is very widely used, most of the large ISPs use it. End consumers are just unaware of that fact. See https://en.wikipedia.org/wiki/IS-IS
Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?
#4I wish we could have another and bump the packet size.
We're at the point where we can have millions of packets per second going through a network interface, and it starts to get very silly.
It's at the point where even a 10G connection requires some thought to actually perform properly. I've managed to get bottlenecked on high end hardware requiring a whole detour into SR-IOV just to get back to decent speeds.
Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?
#5Ironically, this version of the header published in 1980 is what we still use to this day. IMHO Ethernet is one of the of great examples of backwards compatibility in the computing world. Even the wireless standards present frames to the upper layers like they're Ethernet. It's also a counterexample to the bureaucracy of standards bodies --- the standard that actually became widely used was the one that got released…
OSI is very widely used, most of the large ISPs use it. End consumers are just unaware of that fact. See https://en.wikipedia.org/wiki/IS-IS
I think this is a stretch, like saying the X.500 Directory System is widely used based on the fact that PKIX is technically adapting X.509 and thus your TLS certificates depend on the X.500 directory system. End users aren't just "unaware" that it's actually the X.500 system, it functionally isn't the X.500 system, PKIX mandates an "alternate" scheme for the Internet and the directory called for by X.500 has never actually existed.
Likewise then, IS-IS is the protocol that OSI standardized, but we're not using as part of an OSI system.
Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?
#6I wish we could have another and bump the packet size. We're at the point where we can have millions of packets per second going through a network interface, and it starts to get very silly. It's at the point where even a 10G connection requires some thought to actually perform properly. I've managed to get bottlenecked on high end hardware requiring a whole detour into SR-IOV just to get back to decent speeds.
> I wish we could have another and bump the packet size.
The clock precision (100s of ppm) of the NIC oscillators on either side of a network connection gives a physical upper limit on the Ethernet packet size. The space between the packets lets the slower side "catch up". See https://en.wikipedia.org/wiki/Interpacket_gap for more info.
We could use more precise oscillators to have longer packets but at a more expensive cost.
Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?
#7I wish we could have another and bump the packet size. We're at the point where we can have millions of packets per second going through a network interface, and it starts to get very silly. It's at the point where even a 10G connection requires some thought to actually perform properly. I've managed to get bottlenecked on high end hardware requiring a whole detour into SR-IOV just to get back to decent speeds.
MTUs are one of the eternal gremlins of networking, and any choice of MTU will almost certainly be either too large for the present day or too small for the future. 1500 was chosen back when computers ran at dozens of megahertz and it was actually kind of large at the time.
Changing the MTU is awful because parameters like MTU get baked into hardware in the form of buffer sizes limited by actual RAM limits. Like everything else on a network once the network is deployed changing it is very hard because you have to change everything along the path. Networks are limited by the lowest common denominator.
This kind of thing is one of the downsides of packet switching networks like IP. The OSI folks envisioned a network that presented a higher level interface where you'd open channels or send messages and the underlying network would handle all the details for you. This would be more like the classic analog phone network where you make a phone call and a channel is opened and all details are invisible.
It's very loosely analogous to CISC vs RISC where the OSI approach is more akin to CISC. In networking RISC won out for numerous reasons, but its simplicity causes a lot of deep platform details to leak into upper application layers. High-level applications should arguably not even have to think about things like MTU, but they do.
When higher level applications have to think about things like NAT and stateful firewall traversal, IPv4 vs IPv6, port remapping, etc. is where it gets very ugly.
The downside of the OSI approach is that innovation would require the cooperation of telecoms. Every type of connection, etc., would be a product offered by the underlying network. It would also give telecoms a ton of power to nickel and dime, censor, conduct surveillance, etc. and would make anonymity and privacy very hard. It would be a much more managed Internet as opposed to the packet switching Wild West that we got.
Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?
#8Earlier quoted context omitted.
OSI is very widely used, most of the large ISPs use it. End consumers are just unaware of that fact. See https://en.wikipedia.org/wiki/IS-IS
I think this is a stretch, like saying the X.500 Directory System is widely used based on the fact that PKIX is technically adapting X.509 and thus your TLS certificates depend on the X.500 directory system. End users aren't just "unaware" that it's actually the X.500 system, it functionally isn't the X.500 system, PKIX mandates an "alternate" scheme for the Internet and the directory called for by X.500 has never ac…
X.500 is widely used in the form of LDAP and Active Directory, however.
Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?
#9I wish we could have another and bump the packet size. We're at the point where we can have millions of packets per second going through a network interface, and it starts to get very silly. It's at the point where even a 10G connection requires some thought to actually perform properly. I've managed to get bottlenecked on high end hardware requiring a whole detour into SR-IOV just to get back to decent speeds.
(Intentional) jumbo frames at layer 2 and expanded MTUs at layer 3 are certainly available (as you may know). In fact it seems (I am, it should be obvious, not an expert) that using jumbo frames is more or less the common practice by now. There does in fact seem to have been some standards drama about this, too: I can't find it now, but IIRC in the '00s someone's proposal to extend the header protocols to allow the header to indicate a frame size of over 1500 bytes was rejected, and nothing seems to have been done since. At the moment it seems that the best way to indicate max. Ethernet frame sizes of over 1500 is an optional field in LLDP(!) https://www.juniper.net/documentation/us/en/software/junos/u... and the fall-back is sending successively larger pings and seeing when the network breaks(!) https://docs.oracle.com/cd/E36784_01/html/E36815/gmzds.html .
Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?
#10I wish we could have another and bump the packet size. We're at the point where we can have millions of packets per second going through a network interface, and it starts to get very silly. It's at the point where even a 10G connection requires some thought to actually perform properly. I've managed to get bottlenecked on high end hardware requiring a whole detour into SR-IOV just to get back to decent speeds.
(Intentional) jumbo frames at layer 2 and expanded MTUs at layer 3 are certainly available (as you may know). In fact it seems (I am, it should be obvious, not an expert) that using jumbo frames is more or less the common practice by now. There does in fact seem to have been some standards drama about this, too: I can't find it now, but IIRC in the '00s someone's proposal to extend the header protocols to allow the h…
I'm not certain what my point is, but I wanted to mention that jumbo frames don't work over the Internet. More of a LAN thing.