Live data from Hacker News

Email could have been X.400 times better

buttondown.com

81–90 of 211 posts

Re: Email could have been X.400 times better

#81

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…

I was there for ATM, and I'm so freaking glad it lost. It's a prime example of "a camel is a horse designed by committee". A 53 byte cell with a 48 byte payload? Of course! What an excellent idea! We definitely want a 10% overhead on a ludicrously small packet, just so it has tolerable voice latencies if you scale it down to run on a 64Kb DS0, never mind that literally everything in the industry was scaling up to fat…

note that it was 'tolerable latency without echo cancellation in France', most other places had long enough latency anyways that they needed to have it anyways. and of course now everything needs echo cancellation.

I think standards are important, and I'm sad that no one bothers anymore, but stuff like this and the inclusion of interlace in digital video for that little 3 year window when it might have mattered does really sour one on the process.

Re: Email could have been X.400 times better

#82
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…

Doh! Of course it was easier to implement. IETF wants a working open source implementation before standardising. Have you ever tried to implement an ITU standard from just reading the specs? It's hard. Firstly you have to spend a lot of money just to buy the specs. Then you find the spec is written by somebody who has a proprietary product, and is tiptoeing along a line that reveals enough information to keep the sta…

> IETF wants a working open source implementation before standardising.

I don't think that's IETF policy. Individual IETF working groups decide whether to request publication of an RFC, and the availability of open source implementations is a strong argument in favour of publication, but not a hard requirement.

If the IETF standards are sometimes useful, it's more a matter of culture than of policy.

Re: Email could have been X.400 times better

#83

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…

atm did not have cell delivery guarantees. it did have per-connection qos negotiation that could include the loss probability as one of the many metrics that were supported. the only way to provide 'zero loss' is to implement hop-by-hop error detection and retransmission, which is only really done in HPC networks, and some satellite transport schemes where the loss is high and bursty and the latency is high.

however, actually building a functional routing infrastructure that supported QOS was pretty intractable. that was one of several nails in ATMs coffin (I worked a little on the PNNI routing proposal).

edit: I should have admitted that yes, loss does have a relationship to queue depth, but that doesn't result in infinite queues here. it does mean that we have to know the link delay and the target bandwidth and have per-flow queue accounting, which isn't a whole lot better really. some work was done with statistical queue methods that had simpler hardware controllers - but the whole thing was indeed a mess.

Re: Email could have been X.400 times better

#84
post #54
post #46

Earlier quoted context omitted.

Sure, but then you have the problem of figuring out which Sarah Connor in Los Angeles. To say nothing of popular names.

My name is not particularly common although I was the first to claim firstname.lastname@gmail.com. I've been getting email intended for other people with the same name for decades. I've seen estimates that there are only 10,000 people with my last name in the US. Back in the days of local telephone directories, I was always the only one with that last name. Internet scaling is an interesting thing. I don't know if I…

I registered [my HN username]@yahoo.com many, many years ago. Once a year I log into that mail account and I'm always amazed at how many other people have decided to give out that email, at Yahoo! of all places, as their own. Why? Just, why?

Re: Email could have been X.400 times better

#85
post #13

Earlier quoted context omitted.

Not trying to be rude, but If you put your unsubscribe page behind a captcha I am going to mark you as spam and move on.

I don't unsubsubscribe unless I explicitly subscribed in the past. If I did not subscribe in the first place then it's spam (exception for small businesses who may not know better in which case I'll delete or unsubscribe).

I'll try unsubscribing once if it looks like a legitimate org, like someone I actually did business with but didn't expect them to email me. After that, it's going to the junk box to train the server what spam looks like.

Re: Email could have been X.400 times better

#86
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…

Worse is Better: https://web.archive.org/web/20040619155500/http://www.jwz.or...

Re: Email could have been X.400 times better

#87

Earlier quoted context omitted.

No, it’s largely broken because of spam. I don’t want to be signed up to your useless email marketing list, and I want to use an email client that makes unsubscribing as easy as possible.

> I don’t want to be signed up to your useless email marketing list, useless is in the eye of the beholder.

Useless is in the eye of the recipient. The sender doesn't get a vote.

Re: Email could have been X.400 times better

#88
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…

And for a while, telco engineers tried to retrofit Internet to their purposes.

I worked on a network that used RSVP ( https://en.wikipedia.org/wiki/Resource_Reservation_Protocol ) to emulate the old circuit-switched topology. It was kinda amazing to see how it could carve guaranteed-bandwidth paths through the network fabric.

Of course, it also never really worked with dynamic routing and brought in tons of complexity with stuck states. In our network, it eventually was just removed entirely in favor of 1gbit links with VLANs for priority/normal traffic.

Re: Email could have been X.400 times better

#89

This is an example of how simplicity won over features. Not even then, when people with access to computers were probably in the thousands, would anyone liked to type "C=no; ADMD=; PRMD=uninett; O=uninett; S=alvestrand; G=harald" just like in the example of the article.

Is this an example of simplicity winning over features, or an example of features that are advertised but don't exist failing to win over the competition? Some examples from the article: > You could have messaged an entire organization or department This is a mailing list. > So it was possible, say, for one implementation of X.400 to offer X.400 features like recalling a message, in theory at least, when such guarant…

>> You could have messaged an entire organization or department

> This is a mailing list.

The way I understand it, the layering is different. In X.400, multicasting was a feature of the protocol. An SMTP mailing list, on the other hand, is an endpoint that terminates a protocol transaction, and then initiates one transaction for each final recipient.

I guess it boils down to where it is preferable to have the extra complexity: the ITU-T protocols invariably prefer to put it inside the network, while the Internet protocols prefer to put it at the endpoints. The SMTP protocol is simple, and therefore the mailing list software needs to be complex.

Re: Email could have been X.400 times better

#90
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…

> 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.

Post reply on HN