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

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Wed, 18 Mar 2020 21:26:23 +0000

Hi Martin

[GD] First, let me say I'm not a contributor to the SRT draft and don't know what its authors plans are but my organization does use it in production and I was involved in getting MOPS created as a WG to help with just this sort of situation where something from the media operations world touches the IETF world.

[GD] I'm still neutral on the if the IETF should take up work on SRT - hence why I want to see the draft get a good discussion and consideration so we can all be better informed when thinking if this is something the IETF should take up.   

On 3/18/20, 1:26 PM, "dispatch on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

    As this is an entirely new transport protocol, I don't see this as being within the MOPS charter.  This would be something at the scale of a working group, likely in the transport area, if the IETF took it on. 

[GD]. If the IETF took up this work, I agree it would be big enough to bit in a new WG, but there is a lot to learn and discuss before that point.   I propose MOPS works as an good place to do an first presentation and discussion because SRT is a media operations focused protocol.  SRT is used by professional media operations such as production studios, TV studios, and cable operators to move content fast and reliably between acquisition to studio and in distribution from studio to distributors over the Internet.   

[GD] Doing the initial discussion in MOPS lets the proposal receive comments from people who are both IETF knowledge and media operations knowledgeable  - with the hope that a draft like this that is coming in from the media technology world can get help to develop into an IETF style draft before facing the more intense discussion they might be jumping into if it first goes directly to the transport area  

[GD]  I'm not proposing MOPS as a final destination, but more of a next step on the journey.  Acting as a bridge with the media operations world is a big part of the charter of MOPS. The MOPS charter talks about it coordinating with other areas and groups at the IETF and sending things over when appropriate for those other groups to look at. I think SRT is a great example of such a situation.

On 3/18/20, 1:26 PM, "dispatch on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

But several questions come from this:
    
    * is the intent here to transfer change control to the IETF?
    
    * 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.

-glenn

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 18 Mar 2020 18:59:46 -0500

I have opinions about the final destination, but let's sit on them for now.
In the meantime,

On Wed, Mar 18, 2020 at 4:26 PM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

> Hi Martin
>
> [GD] First, let me say I'm not a contributor to the SRT draft and don't
> know what its authors plans are but my organization does use it in
> production and I was involved in getting MOPS created as a WG to help with
> just this sort of situation where something from the media operations world
> touches the IETF world.
>
> [GD] I'm still neutral on the if the IETF should take up work on SRT -
> hence why I want to see the draft get a good discussion and consideration
> so we can all be better informed when thinking if this is something the
> IETF should take up.
>
> On 3/18/20, 1:26 PM, "dispatch on behalf of Martin Thomson" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     As this is an entirely new transport protocol, I don't see this as
> being within the MOPS charter.  This would be something at the scale of a
> working group, likely in the transport area, if the IETF took it on.
>
>
> [GD]. If the IETF took up this work, I agree it would be big enough to bit
> in a new WG, but there is a lot to learn and discuss before that point.   I
> propose MOPS works as an good place to do an first presentation and
> discussion because SRT is a media operations focused protocol.  SRT is used
> by professional media operations such as production studios, TV studios,
> and cable operators to move content fast and reliably between acquisition
> to studio and in distribution from studio to distributors over the
> Internet.
>
> [GD] Doing the initial discussion in MOPS lets the proposal receive
> comments from people who are both IETF knowledge and media operations
> knowledgeable  - with the hope that a draft like this that is coming in
> from the media technology world can get help to develop into an IETF style
> draft before facing the more intense discussion they might be jumping into
> if it first goes directly to the transport area
>
> [GD]  I'm not proposing MOPS as a final destination, but more of a next
> step on the journey.  Acting as a bridge with the media operations world is
> a big part of the charter of MOPS. The MOPS charter talks about it
> coordinating with other areas and groups at the IETF and sending things
> over when appropriate for those other groups to look at. I think SRT is a
> great example of such a situation.
>

MOPS as an initial point of contact does make sense to me, and is
consistent with the various efforts that IESGs and IABs have made over at
least a couple of decades to drag operational problems into the IETF so we
could find out if we can help.

My first question would be "does this protocol work the way you need it to
work, and you just want a stable specification, or is there still protocol
engineering work to do?". The answer to that question would tell me a lot,
and I don't know that talking about this in Dispatch would be as helpful. I
haven't been around Dispatch a lot in recent years, but is there still an
undercurrent of "we know what we want to do, and need to know where to do
it" in Dispatch?

IMO, of course.

Best,

Spencer

> On 3/18/20, 1:26 PM, "dispatch on behalf of Martin Thomson" <
> [email-masked] on behalf of [email-masked]> 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.
>
>
> -glenn
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 19 Mar 2020 11:22:34 +1100

> [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 loc…

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/

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Thu, 19 Mar 2020 08:42:39 +0700

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 <[email-masked]> wrote:

> 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,
>
> --

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

   -

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Mar 2020 19:11:58 -0700

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 20 Mar 2020 12:15:57 +0000

> On 19 Mar 2020, at 00:22, Mark Nottingham <[email-masked]> wrote:

Or on top of Secure RTP and RTSP, which seem to occupy a very similar space to SRT.

-- 
Colin Perkins
https://csperkins.org/

---

From: Maxim Sharabayko <[email-masked]>
Date: Sun, 22 Mar 2020 13:10:52 +0000

Hi everyone!

Thanks for paying interest to SRT!

I was hoping to get at least 10 minutes to go quickly through SRT on the dispatch meeting on Monday. But looks like the chances to get this time slot are relatively low.
To address this topic I have recorded a video of my presentation and uploaded it here:
https://youtu.be/VrE3dJej5IE
It is 12 minutes long and goes relatively quickly over the main features and mechanisms of the Secure Reliable Transport protocol.
I hope this quick overview will help to save everyone's time and to improve the quality of our discussion on Monday.

-- 

Regards,
Maxim Sharabayko

---

From: Patrick McManus <[email-masked]>
Date: Mon, 23 Mar 2020 16:08:03 -0400

fwiw I did send avtcore a heads up that this presentation was happening on
a as time allowed basis.

-Patrick

On Wed, Mar 18, 2020 at 9:43 PM Alexandre GOUAILLARD <[email-masked]>
wrote:

> 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 19 Mar 2020, at 8:26 am, Deen, Glenn (NBCUniversal) <
>> [email-masked] <[email-masked]>> wrote:
>> >