Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ethernet History Deepdive – Why Do We Have Different Frame Types?

lostintransit.se

Post reply on HN
Print view View original

21–30 of 86 posts

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#21

Post by thfuran »

throwup238 wrote: post #18
dale_glass wrote: post #4

I 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. That's why I'm in full support of a world ending apocalypse that allows society to restart from scratch. We've made so many bad decisions this time around, with packet sizes being some of the worst.

As long as we also make sure electrons are positively charged this time.

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#22

Post by p_l »

tristor wrote: post #15
layer8 wrote: post #8

Earlier quoted context omitted.

X.500 is widely used in the form of LDAP and Active Directory, however.

Active Directory is not based on X.500 and LDAP was directly created as an alternative to the DAP standard that is part of X.500. While X.500 is a precursor to both of these things, and influenced both of these things, and both of these things interoperated with X.500, they are not X.500. X.500 is for all intents and purposes pretty much dead in 2024, although I did deploy an X.500 based directory service in 2012 and…

LDAP is just "lightweight" protocol for accessing an X.500 directory service.

The semantics are the same for the accessed store, IIRC. The protocol definition explicitly talks about being used to access X.500 data stores as complementary interface to DAP (which requires lower layers of OSI stack vs LDAP's raw stream of bytes)

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#23

Post by tristor »

p_l wrote: post #22
tristor wrote: post #15

Earlier quoted context omitted.

Active Directory is not based on X.500 and LDAP was directly created as an alternative to the DAP standard that is part of X.500. While X.500 is a precursor to both of these things, and influenced both of these things, and both of these things interoperated with X.500, they are not X.500. X.500 is for all intents and purposes pretty much dead in 2024, although I did deploy an X.500 based directory service in 2012 and…

LDAP is just "lightweight" protocol for accessing an X.500 directory service. The semantics are the same for the accessed store, IIRC. The protocol definition explicitly talks about being used to access X.500 data stores as complementary interface to DAP (which requires lower layers of OSI stack vs LDAP's raw stream of bytes)

Yes, that is why it was invented, as I alluded to. LDAP was an alternative to DAP. DAP is part of the X.500 standard, LDAP is not. LDAP when it was first invented was built to access an X.500 directory. That is no longer a base requirement and most directories in the wild are not built on X.500. Standards mean things, just because LDAP was originally built to access X.500 doesn't mean it's part of X.500, and X.500 is a very detailed and specific standard which most directory services no longer follow.

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#24

Post by Hikikomori »

betaby wrote: post #3
userbinator wrote: post #2

Ironically, 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

Would call it stretch to say it was widely used by ISPs. Some old ones may still be using integrated IS-IS as their IGP (early OSPF had scaling issues and complicated solutions for that), but that's nothing like widely using the ISO stack. But they might have used IS-IS it to route NSAP in their network at some point in time to manage ATM-era equipment, the ISP I worked still had some ctunnels for that purpose, I doubt they still have them.

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#25

Post by mannyv »

One thing that isn't mentioned is that the physical layer at the time was 'flat' ie: a network had a shared wire. That means bus arbitration (to prevent collisions) was a big deal. Token ring solved that by passing tokens, which presumably guarantees latency. I believe Ethernet just raised a line high, and it was up to everyone to respect that.

Of course that changed when switches came out. I have a 10/100 hub in a closet somewhere for debugging, since it's nice to not have to remember how to get into a switch and set the monitor port.

Token ring equivalents are still used in lots of places. From what I remember cable modem data is basically token ring off of channel 0 (though that may not be accurate anymore).

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#26

Post by HappMacDonald »

amelius wrote: post #19
throwup238 wrote: post #18

Earlier quoted context omitted.

> I wish we could have another and bump the packet size. That's why I'm in full support of a world ending apocalypse that allows society to restart from scratch. We've made so many bad decisions this time around, with packet sizes being some of the worst.

Maybe we can then also redefine pi as 2*pi, while we're at it.

Or just use tau and call it "tau"

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#27

Post by GauntletWizard »

tristor wrote: post #23
p_l wrote: post #22

Earlier quoted context omitted.

LDAP is just "lightweight" protocol for accessing an X.500 directory service. The semantics are the same for the accessed store, IIRC. The protocol definition explicitly talks about being used to access X.500 data stores as complementary interface to DAP (which requires lower layers of OSI stack vs LDAP's raw stream of bytes)

Yes, that is why it was invented, as I alluded to. LDAP was an alternative to DAP. DAP is part of the X.500 standard, LDAP is not. LDAP when it was first invented was built to access an X.500 directory. That is no longer a base requirement and most directories in the wild are not built on X.500. Standards mean things, just because LDAP was originally built to access X.500 doesn't mean it's part of X.500, and X.500 is…

To reiterate in a slightly different form: Ldap is an inheritor of, and successor to, DAP/X.500, but not backwards compatible and only superficially resembling it at this point.

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#28

Post by kstrauser »

leoc wrote: post #9
dale_glass wrote: post #4

I 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…

The common advice I've heard for jumbo frames is not to enable them unless you can do it for every devices on your LAN, and even then it's probably not worthwhile outside specific situations like a separate iSCSI network or such.

I just now ran iperf3 from my Mac to my Synology without jumbo frames:

  [ ID] Interval           Transfer     Bitrate         Retr
  [  7]   0.00-10.00  sec  10.0 GBytes  8.61 Gbits/sec    0             sender
  [  7]   0.00-10.00  sec  10.0 GBytes  8.60 Gbits/sec                  receiver
Given how rarely I actually care to saturate the 10Gbit link, I'd rather use the slightly hypothetically slower default settings that are highly likely to work in all scenarios.

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#29

Post by fanf2 »

rjsw wrote: post #13
userbinator wrote: post #2

Ironically, 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 was usable as a wide area network before TCP/IP was.

[citation needed]

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#30

Post by akira2501 »

mannyv wrote: post #25

One thing that isn't mentioned is that the physical layer at the time was 'flat' ie: a network had a shared wire. That means bus arbitration (to prevent collisions) was a big deal. Token ring solved that by passing tokens, which presumably guarantees latency. I believe Ethernet just raised a line high, and it was up to everyone to respect that. Of course that changed when switches came out. I have a 10/100 hub in a c…

> I believe Ethernet just raised a line high, and it was up to everyone to respect that.

It's actually much simpler than that. When you transmit you also listen. If what you hear is not what you sent, there is a collision, and you backoff.

Post reply on HN