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

[Spencer Dawkins at IETF <[e-mail]>]

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) <
[e-mail]> 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" <
> [e-mail] on behalf of [e-mail]> 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" <
> [e-mail] on behalf of [e-mail]> 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
>
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>