> > *nods* Well, and that's the rub. Their expectations don't match any > Internet SLA I've ever seen, much less for standard broadband. However, > simply telling the customer that we're within our SLA or proving it's not > our fault doesn't do much to enhance customer satisfaction and thus doesn't > help our reputation. Hearing from others that the broadcast industry has > already figured this problem out and sends the same stream via multiple > paths is a big help in getting us going in the right direction.
If we assume that these 6 1s interruptions are actually the fault of the network providing the connectivity, then you're already much better than 6 9s of reliability, as Jay said. You'd be hard pressed to get much better. But again, without technical proof here that the network service itself is actually the cause of the issue, you're kind of in the tall grass still. We had broadcast video teams internally years ago that would come to us with all kinds of similar 'small burp' problems, and blame the network for it. In 95% of cases, the problem turned out to be their equipment or applications doing it to themselves. Had nothing to do with the network at all. Hundreds of hours were sunk proving that. You don't have to meet every expectation of every subscriber. It's totally fair for you to say "It appears as if the service we provide may not be suitable for your needs. We'd be happy to continue to provide you services, but it may be beneficial for you to investigate other options." Reasonable people will respect that. Unreasonable people stomp their feet and yell, but those people are going to stomp their feet and yell no matter what. On Mon, Sep 15, 2025 at 8:07 AM Mike Hammett via NANOG < [email protected]> wrote: > *nods* Well, and that's the rub. Their expectations don't match any > Internet SLA I've ever seen, much less for standard broadband. However, > simply telling the customer that we're within our SLA or proving it's not > our fault doesn't do much to enhance customer satisfaction and thus doesn't > help our reputation. Hearing from others that the broadcast industry has > already figured this problem out and sends the same stream via multiple > paths is a big help in getting us going in the right direction. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > From: "Saku Ytti" <[email protected]> > To: "North American Network Operators Group" <[email protected]> > Cc: "Mike Hammett" <[email protected]> > Sent: Monday, September 15, 2025 2:13:40 AM > Subject: Re: Resilient Internet > > On Sun, 14 Sept 2025 at 23:29, Mike Hammett via NANOG > <[email protected]> wrote: > > > I have a radio station customer who is utilizing one of those streaming > services to bring their broadcast station online. We've received a > complaint of a half dozen or so 1-second drops in connectivity over the > Internet to this streaming service in the six or so months they've been a > customer. I consider that pretty amazing service delivery. However, the > customer does not. I suspect this is a layer 8 issue, but what have your > experiences been in these kinds of situations, and what technical remedies > would be available? I don't know what sub-second failover systems exist, > but I'm sure they're not cost-effective if they do. > > Lot more information would be needed to meaningfully contribute. > > But generally speaking if the price expectation is anywhere near what > Internet services typically are, the customer is definitely asking too > much. And your contract terms should make it clear that this level of > service availability is within the SLA. > > Having said that, I used to work for a company that provides streams > for terrestrial tv. Not IP-TV, regular antenna TV. How this was done > was that there was dual-plane MPLS/IP backplane and the stream was > sent through both planes, at the antenna site a duplicate packet was > dropped before content was fed to the transmitters. > If you have a very high expectation of availability, you'll very > quickly find that you either do it twice or you do it once and break > SLA and apologise regularly. > > > > -- > ++ytti > > > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/KJNGBFS4ZW53ENJIBNN5TUMX27JJ5TMZ/ > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/S23EA7C5VPBEARI64DL5PABLSBMXUH2U/
