Live data from Hacker News

Email could have been X.400 times better

buttondown.com

121–130 of 211 posts

Re: Email could have been X.400 times better

#121
post #14

>> SMTP "“didn’t win because it was ‘better,’” he argued, but “just because it was easier to implement." Yes - and this is actually really important! It's true of most of the important early internet technologies. It's the entire reason "internet" standards won over "telco" (in this case ITU) standards - the latter could only be deployed by big coordinated efforts, while internet standards let individual decentralize…

> It's the entire reason "internet" standards won over "telco" (in this case ITU) standards - the latter could only be deployed by big coordinated efforts, Anyone remember the promise of ATM networking in the 90's? It was telecom grade networking which used circuit switched networking that would handle voice, video and data down one pipe. Instead of carelessly flinging packets into the ether like an savage, you had a…

Anyone remember the incredible disrepute of the phone company in the 80s?

We just wanted our own stuff. We did not want to coordinate with a proprietary vendor to network or be charged by the byte to do so.

Re: Email could have been X.400 times better

#122
post #90

Earlier quoted context omitted.

> Instead of carelessly flinging packets into the ether like an savage, you had a deterministic network of pipes I love this. Ethernet is such shit. What do you mean the only way to handle a high speed to lower speed link transition is to just drop a bunch of packets? Or sending PAUSE frames which works so poorly everyone disables flow control.

Wait, are you serious? This is how it works?

This is how old-school TCP figures out how fast it can send data, regardless of the underlying transport. It ramps up the speed until it starts seeing packet loss, then backs off. It will try increasing speed again after a bit, in case there's now more capacity, and back off again if there's loss.

Re: Email could have been X.400 times better

#123
post #117

SMTP won because it was simpler, but it's probably good to look at why it was simpler. SMTP handled routing by piggybacking on DNS. When an email arrives the SMTP server looks at the domain part of the address, does a query, and then attempts transfer it to the results of that query. Very simple. And, it turns out, immensely scalable. You don't need to maintain any routing information unless you're overriding DNS for…

Ehhh.. This is a bit revisionist for a couple reasons. 1. smtp predates dns. or really even most of the internet. It was originally designed to work over uucp. 2. early smtp used bang paths (remember those) where the route or partial route is baked into the path.

Of course, for reliability, you could even bake multiple paths into the envelope address.

Re: Email could have been X.400 times better

#124
wow, how to romanticize X.400 ...

- poor Internet fit, assuming managed, trusted networks - some promises depended on all participating systems behaving honestly

- once a message reaches another server, you cannot guarantee it isn't copied, backed up, or logged

- X.400 read receipts: more reliable but also more privacy invasive

- X.400 metadata: carries a lot of routing, classification, and organizational info leading to potential privacy leaks

- SMTP is ugly but observable, you don't need a standard specialist to debug issues

Re: Email could have been X.400 times better

#125
post #90

Earlier quoted context omitted.

> Instead of carelessly flinging packets into the ether like an savage, you had a deterministic network of pipes I love this. Ethernet is such shit. What do you mean the only way to handle a high speed to lower speed link transition is to just drop a bunch of packets? Or sending PAUSE frames which works so poorly everyone disables flow control.

Wait, are you serious? This is how it works?

Yes: https://fasterdata.es.net/performance-testing/troubleshootin.... A simplistic TCP server will blast packets on the link as fast as it can, up to the size of the TCP receive window. At that point it’ll stop transmitting and wait for an ACK from the client before sending another window’s worth of packets.

To handle a speed transition without dropping packets, the switch or router at the congestion point needs to be able to buffer the whole receive window. It can hold the packets and then dribble them out over the lower speed link. The server won’t send more packets until the client consumes the window and sends an ACK.

But in practice the receive window for an Internet scale link (say 1 gigabit at 20 ms latency) is several megabytes. If the receive window was smaller than that, the server would spend too much time waiting for ACKs to be able to saturate the link. It’s impractical to have several MB of buffer in front of every speed transition.

Instead what happens is that some switch or router buffer will overflow and drop packets. The packet loss will cause the receive window, and transfer rate, to collapse. The server will then send packets with a small window so it goes through. Then the window will slowly grow until there’s packet loss again. Rinse and repeat. That’s what causes the saw-tooth pattern you see on the linked page.

Re: Email could have been X.400 times better

#126
post #14

>> SMTP "“didn’t win because it was ‘better,’” he argued, but “just because it was easier to implement." Yes - and this is actually really important! It's true of most of the important early internet technologies. It's the entire reason "internet" standards won over "telco" (in this case ITU) standards - the latter could only be deployed by big coordinated efforts, while internet standards let individual decentralize…

At the time, when there were so many different platforms still in existence, "easier to implement" was in fact a major component of "better".

Re: Email could have been X.400 times better

#127
post #90

Earlier quoted context omitted.

> Instead of carelessly flinging packets into the ether like an savage, you had a deterministic network of pipes I love this. Ethernet is such shit. What do you mean the only way to handle a high speed to lower speed link transition is to just drop a bunch of packets? Or sending PAUSE frames which works so poorly everyone disables flow control.

Wait, are you serious? This is how it works?

Heh heh. If that shocks you, search engine for "bufferbloat" and prepare to be horrified.

Re: Email could have been X.400 times better

#128
post #25

Earlier quoted context omitted.

> Ethernet had to adapt to deterministic real-time needs Without being able to get too into the telco detail, I think the lesson was that hard realtime is both much harder to achieve and not actually needed . People will happily chat over nondeterministic Zoom and Discord. It's both psychological and slightly paradoxical. Once you let go of saying "the system MUST GUARANTEE this property", you get a much cheaper, bet…

I saw a story once, which may well be completely made up, about why AT&T got out of the cell phone business. They had a research project, but reliability was an issue. They couldn't see a way to do better than 1 dropped call in 10,000. Their standard for POTS at the time was 1 in 2 billion. Seeing that the tech would never be good enough, they sold off the whole thing for cheap. Years later, they bought it back for w…

Seems a little sus. AT&T basically created the cellular mobile phone, and built up an analog, then digital system (D-AMPS/TDMA). AT&T sort of sold out the mobile business in 2004 to Cingular (BellSouth) because TDMA was a dead end. They then bought BellSouth back in 2006 and carried on with CDMA.

Those old phones had a long range. It was hard to make small ones because the old AT&T towers were much farther apart, up to 40km. Meanwhile, their competitors focused on smaller coverage areas (e.g. 2km or less for PCS) and better tech (CDMA), and it seemed to pay off.

Re: Email could have been X.400 times better

#129
post #99

I still think the missing opportunity with e-mail was for the USPS (back in the US-dominant internet days) to take a leading role and implement "e-stamps." Provide a subscription service that managed a per-user account, cost a 1¢ stamp to send a message, and guaranteed delivery of messages received with a 1¢ stamp on them -- with the received stamp value being put in the user's account, so a user who received more ma…

> We could have had a world without spam

I doubt it. USPS charges everyone to send snail mail, and I get plenty of spam in my mailbox. I end up with way more spam in my snail mailbox than in my email inbox, since the latter has filtering.

Re: Email could have been X.400 times better

#130

Earlier quoted context omitted.

> It's the entire reason "internet" standards won over "telco" (in this case ITU) standards - the latter could only be deployed by big coordinated efforts, Anyone remember the promise of ATM networking in the 90's? It was telecom grade networking which used circuit switched networking that would handle voice, video and data down one pipe. Instead of carelessly flinging packets into the ether like an savage, you had a…

ATM was superior in the context of a bill-by-the-byte telco-style network where oversubscribed links could be carefully planned. The "impedance mismatch" IP's of unreliable datagram delivery with ATM's guaranteed cell delivery created situations where ATM switches could effectively need unlimited buffer RAM to make their delivery guarantees even if the cells were containing IP datagrams that could just be discarded w…

It was designed by people who were trying to digitally emulate 1920s copper-wire circuits at a time when the entire world was moving to packet-switched digital data. I remember visiting a large telco at the time and having to tell them about this new thing called ADSL that was going to steamroller them if they weren't careful. "Nooo... no, that's not real, you can't do that over a phone line, not possible. And even if it was it'll never take off, if anyone really wants a digital link they can go with our X.25 or ISDN offerings".

When I pointed out in a previous post how much X.400 sucked, even that never got anywhere near X.25. X.25 is the absolute zero on any networking scale, the scale starts with X.25 at -273degC and goes up from there.

Post reply on HN