It's simpler, but you can use coding to spackle over larger gaps than TCP can usually manage, and it doesn't require the round-trips for retransmissions, you just encode with enough redundancy to deal with the design allowed for gap sizes.
On Mon, Sep 15, 2025 at 3:54 PM nanog--- via NANOG <[email protected]> wrote: > There's also the substantially easier option of keeping a buffer of > longer than one second, and using TCP (do some testing to make sure it > will actually retransmit packets within the buffer timeout. Likely > already the case due to SACK.). > > On 15/09/2025 14:37, Dorn Hetzel via NANOG wrote: > > If they can bend the application they are using, and don't mind > significant > > latency, something like RaptorQ codes with deep time interleaving can > > spackle over considerably larger gaps than 1 seconds, at the cost of some > > additional overhead. > > > > On Mon, Sep 15, 2025 at 2:07 PM 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/Z5HYQHC7QPBPMXU7PDZ3L7VWG3OHQTD4/ > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/QTE2G2FVRIMVGXGQQ5NQIIWA67SYXNC4/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/WEXGXLXKJ3UO3TC77B2TW6PWKMZ7XNND/
