Re: [dispatch] Virtual IETF107

I share Mark and MT's questions.

I would encourage the proponents to focus their presentation on what
functionality SRT provides that QUIC and/or SRTP does not (and that cannot
be easily grafted on). That seems like the most productive conversation to
have.

-Ekr

On Wed, Mar 18, 2020 at 5:22 PM Mark Nottingham <mnot@mnot.net> wrote:

> On 19 Mar 2020, at 8:26 am, Deen, Glenn (NBCUniversal) <
> Glenn.Deen@nbcuni.com> wrote:
> >
> >    * why would anyone choose to do this as opposed to something like
> QUIC?  QUIC provides certain security properties, whereas I have very
> little confidence in the claimed security properties of this protocol.
> >
> > [GD] SRT has reliable delivery features that are needed for media
> distribution and are not part of QUIC and wouldn't be likely to be added to
> QUIC.  So QUIC isn't a replacement for SRT, though it is entirely possible
> that at some point SRT may be run over QUIC.
> >
> > [GD] SRT has features that meet media specific needs.  For example
> consider the need to reliably deliver a live sporting event quickly from
> the stadium to the distribution carriers such as your local TV station or
> cable company or streaming operator. It's used when the media stream MUST
> arrive at the studio and can't tolerate retrains.  It's not only for live
> events but such events are a great use-case for the Reliable aspects of SRT.
>
> QUIC has reliable delivery of streams by default, and the WG has just
> adopted <https://tools.ietf.org/html/draft-ietf-quic-datagram-00> for
> unreliable delivery. Is there any feature of SRT that can't be built on top
> of those primitives?
>
> I'd suggest that doing so is a much quicker (no pun intended) path to
> standardisation, in that the design work on QUIC's encryption and transport
> features is getting very close to done. SRT would need to be evaluated
> against a number of design criteria -- including not only security and
> privacy, but also network fairness -- to start, and it'd still need to go
> through the consensus process.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

Re: [dispatch] Virtual IETF107 - SRT draft is available