Re: Resilient Internet

[Pedro Prado via NANOG <nanog () lists nanog org>]

IIUC the application needs interactivity which is not great with lots of buffering. Sorry if I’m off, that was my 
impression. 

If you already know you’ll have some loss, that implies some packets _will_ be lost; IMHO duplication is most likely 
the only way to significantly lessen the losses. Retransmissionalgorithms are susceptible to being affected again on 
the retransmission, worsening the delay.

Btw, I’ve heard of duplication even over the _same link_ because it was detected to be lossy, just to increase the odds 
one of the duplicates would make it.

Pedro Martins Prado
pedro.prado () gmail com / +353 83 036 1875

> On 15 Sep 2025, at 15:21, Dorn Hetzel via NANOG <nanog () lists nanog org> wrote:
>
> 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 <nanog () lists nanog org>
> 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 <
> > > nanog () lists nanog org> 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" <saku () ytti fi>
> > > > To: "North American Network Operators Group" <nanog () lists nanog org>
> > > > Cc: "Mike Hammett" <nanog () ics-il net>
> > > > 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
> > > > <nanog () lists nanog org> 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/nanog () lists nanog org/message/KJNGBFS4ZW53ENJIBNN5TUMX27JJ5TMZ/
> > > >
> > > _______________________________________________
> > > NANOG mailing list
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/Z5HYQHC7QPBPMXU7PDZ3L7VWG3OHQTD4/
> > _______________________________________________
> > NANOG mailing list
> >
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/QTE2G2FVRIMVGXGQQ5NQIIWA67SYXNC4/
> _______________________________________________
> NANOG mailing list 
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/WEXGXLXKJ3UO3TC77B2TW6PWKMZ7XNND/

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/RW76EDEKDAQWLBL7USUKQIZZ5UKOIYBS/