Re: [dispatch] Virtual IETF107

In any aspects, SRT seems to address the same need that (old) SRTP has been
trying to achieve, and more recent media transport protocols are trying to
achieve as well (rtcweb, quic datagrams). Perhaps having the folks over
from AVTCORE could help bring in the right expertise? Maybe jonathan
Lennox? With Mark and Ekr in the room, there is enough expertise already to
cover QUIC and SRTP/rtcweb.

On Thu, Mar 19, 2020 at 7:22 AM 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
>

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

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