6 ms·

> Their SLA with their customers was something like three minutes of downtime per decade. That is insane. I really feel like modern SLAs are only getting worse

by yunohn 4y ago

> Their SLA with their customers was something like three minutes of downtime per decade. That is insane. I really feel like modern SLAs are only getting worse - so much so that most companies fudge them, and try their hardest to never declare any sort of outage.

wincy 4y ago
What do you mean, Microsoft 358 is an excellent product that has uptime for exactly what they’ve got on the label!
- deleted 4y ago
  [deleted]
gumby 4y ago
The Bell System standard was an extremely high Erlang number, which of course they strove to provide at the lowest cost which meant extremely high utilization rate on hardware which in turn meant extreme uptime (compare to the then contemporary PTT QoS even in major economies like France). This is also why the software itself was designed with so many internal defenses and what I would consider an “immune system”. I’ve never seen anything like it even on an aircraft control system. That is mentioned in passing in the brief article but is easily missed if you don’t know what it’s referring to. Most of what is done on the Internet at, say, “layer 5 or above” isn’t at all important so there’s no need for this level of SLA, but the actual backbone carriers do still carry SLAs at around that level. With packet switching it’s easier for them to provide than it was in the days of the 4ESS and 5ESS.
- vatys 4y ago
  > The Bell System standard was an extremely high Erlang number I wasn't aware of erlang the unit (measuring telephone circuit load) and at first thought this had something to do with the language. https://en.wikipedia.org/wiki/Erlang_(unit) https://en.wikipedia.org/wiki/Erlang_(unit)
  - gumby 4y ago
    Well, they are related in that they are both telephony related: the language was an internal Ericsson language for building fast switches and such devices. I am always surprised (though I shouldn’t be) when I see it mentioned in a non-telecom context.
  - smingo 4y ago
    Someone must have felt very clever when they concluded Erlang would be dimensionless. Calls per second X seconds per call = no unit. But that's wrong. Clearly the number of calls ongoing maps on to lines being used for a circuit-switched network, or datagrams in flight, or whatever. Far from dimensionless. Call_starts per second X call.seconds per call_start = calls as the unit Much more plausible, IMHO.
rubatuga 4y ago
Worst are SLAs where you have to prove the outage as a customer like wtf
foobiekr 4y ago
Most modern SLAs are worthless. The penalty is meaningless and/or "up" is carefully defined in such a way that even a service failing 100% of requests is "up" because it's responding, or is defined such that a single customer can have a total outage but the service is up because it's servicing others. Networking is the last bastion of SLAs that actually seem to matter.
kjellsbells 4y ago
Telco is a highly regulated business. If you go down, the FCC and the state regulator are all over you. If you break 911 service, heaven help you. As a result, five or six nines availability is pretty standard. Six nines means you can lose no more than 31 seconds a year. As a result, traditional telco had all kinds of cool tech in it, eg the Nortel DMS had live code patching as early as 1990 iirc. At one time I worked at a vendor of IP telco switches, aiming to replace the legacy Nortel and Lucent with smaller tech. We had to learn some very, very hard lessons about reliability, but we eventually got there. Today, I see cloud hyperscalers claiming that can run telco workloads, but I remain pretty skeptical until they can prove that they can switch a call, mid stream, from one node to another, without losing the audio, while transcoding it from one codec to another. Im not saying that public cloud needs to make the same tech choices re resilience, but today's web tech absolutely will not cut it.
- toast0 4y ago
  > Today, I see cloud hyperscalers claiming that can run telco workloads, but I remain pretty skeptical until they can prove that they can switch a call, mid stream, from one node to another, without losing the audio, while transcoding it from one codec to another. Im not saying that public cloud needs to make the same tech choices re resilience, but today's web tech absolutely will not cut it. The thing is, traditional telco can't do it anymore either. CenturyLink (aka Lumen) has broken 911 at least twice since 2018 when I moved into their territory. I've got the county emergency dispatch center in my address book, cause chances are, they'll do it a couple more times.

by yunohn 4y ago

wincy 4y ago

What do you mean, Microsoft 358 is an excellent product that has uptime for exactly what they’ve got on the label!

deleted 4y ago
[deleted]

gumby 4y ago

The Bell System standard was an extremely high Erlang number, which of course they strove to provide at the lowest cost which meant extremely high utilization rate on hardware which in turn meant extreme uptime (compare to the then contemporary PTT QoS even in major economies like France). This is also why the software itself was designed with so many internal defenses and what I would consider an “immune system”. I’ve never seen anything like it even on an aircraft control system. That is mentioned in passing in the brief article but is easily missed if you don’t know what it’s referring to. Most of what is done on the Internet at, say, “layer 5 or above” isn’t at all important so there’s no need for this level of SLA, but the actual backbone carriers do still carry SLAs at around that level. With packet switching it’s easier for them to provide than it was in the days of the 4ESS and 5ESS.

vatys 4y ago
> The Bell System standard was an extremely high Erlang number I wasn't aware of erlang the unit (measuring telephone circuit load) and at first thought this had something to do with the language. https://en.wikipedia.org/wiki/Erlang_(unit) https://en.wikipedia.org/wiki/Erlang_(unit)
- gumby 4y ago
  Well, they are related in that they are both telephony related: the language was an internal Ericsson language for building fast switches and such devices. I am always surprised (though I shouldn’t be) when I see it mentioned in a non-telecom context.
- smingo 4y ago
  Someone must have felt very clever when they concluded Erlang would be dimensionless. Calls per second X seconds per call = no unit. But that's wrong. Clearly the number of calls ongoing maps on to lines being used for a circuit-switched network, or datagrams in flight, or whatever. Far from dimensionless. Call_starts per second X call.seconds per call_start = calls as the unit Much more plausible, IMHO.

rubatuga 4y ago

Worst are SLAs where you have to prove the outage as a customer like wtf

foobiekr 4y ago

Most modern SLAs are worthless. The penalty is meaningless and/or "up" is carefully defined in such a way that even a service failing 100% of requests is "up" because it's responding, or is defined such that a single customer can have a total outage but the service is up because it's servicing others. Networking is the last bastion of SLAs that actually seem to matter.

kjellsbells 4y ago

Telco is a highly regulated business. If you go down, the FCC and the state regulator are all over you. If you break 911 service, heaven help you. As a result, five or six nines availability is pretty standard. Six nines means you can lose no more than 31 seconds a year. As a result, traditional telco had all kinds of cool tech in it, eg the Nortel DMS had live code patching as early as 1990 iirc. At one time I worked at a vendor of IP telco switches, aiming to replace the legacy Nortel and Lucent with smaller tech. We had to learn some very, very hard lessons about reliability, but we eventually got there. Today, I see cloud hyperscalers claiming that can run telco workloads, but I remain pretty skeptical until they can prove that they can switch a call, mid stream, from one node to another, without losing the audio, while transcoding it from one codec to another. Im not saying that public cloud needs to make the same tech choices re resilience, but today's web tech absolutely will not cut it.

toast0 4y ago
> Today, I see cloud hyperscalers claiming that can run telco workloads, but I remain pretty skeptical until they can prove that they can switch a call, mid stream, from one node to another, without losing the audio, while transcoding it from one codec to another. Im not saying that public cloud needs to make the same tech choices re resilience, but today's web tech absolutely will not cut it. The thing is, traditional telco can't do it anymore either. CenturyLink (aka Lumen) has broken 911 at least twice since 2018 when I moved into their territory. I've got the county emergency dispatch center in my address book, cause chances are, they'll do it a couple more times.