Re: [AVTCORE] [payload] MMTP vs RTP

[Gorry Fairhurst <[e-mail]>]

I can offer a little context here (but not the presenter):

A proposal was received to the TSV Area that asked if the IETF would be 
able to work on transport methods for the new MMT specification. This 
IETF meeting we had a very short "heads up" presentation in the TSV-Area 
meeting in Prague to open this discussion (see proceedings).

I udnerstand the first version of the MMT specs had been published, 
together with considerations about how to transmit this directly over 
broadcast TV multiplexes. Thought had also been given on how to go 
beyond the MPEG-2 Transport Stream concepts to provide much more 
flexible packetisation and multiplexing, and to target IP networks - 
they also want to work with hybird networks that combine multiple 
delivery methods.

The presentation I saw at the IETF suggested this work was open to IETF 
inputs - expecting methods for real-time delivery and a carousel-based 
reliable transport framework. Although there are Specs, and RTP was 
already evaluated and found to not be directly suitable, I heard that 
there is a hope to define the new methods within the IETF. I can't speak 
for all involved, I'm currently only watching what goes on, but I think 
this may be a case of not bringing a transport spec to the IETF, but 
more of bringing a multimedia architecture and asking how to transport 
it. It's early stages.

Gorry
(TSVWG Co-Chair)

On 28/07/2015 23:40, Michael Speer wrote:
> All,
>
> I agree with you that it’s not clear if MMT is a good candidate to replace all uses of RTP. When we worked on MPEG-TS Payload format
> years ago, there where a number of challenges including the fact MPEG-TS was not really suited to packet networks such as IP.   My
> main question is whether MMT overcomes many of packetization issues we dealt with at the time.  RTP does quite well for a variety
> of applications as we all know, so let’s be careful about use of the words replace.   For MPEG streams, it may well be the case, this
> improves the situation for some applications.
>
> The relevant combination of RFCs are to provide context are RFC 3360, RFC 2250, RFC 5691 and RFC 3640.  The last
> three RFCs provide MPEG packetization history.
>
> Cheers,
> Michael
>
>
>> On Jul 28, 2015, at 12:00 PM, Thomas Edwards<[e-mail]>  wrote:
>>
>> I will add that MMT is under study by the ATSC TG3/S33 "Specialist Group on Management and Protocols" to be a transport in the ATSC 3.0 digital broadcast television standard.
>>
>> It is not yet clear to me if MMT is a good candidate to replace all uses of RTP, but it certainly appears to be a good candidate to replace the use of MPEG Transport Streams for delivery of completed linear content over IP systems.
>>
>> -Thomas
>>
>> -- 
>> Thomas Edwards
>> VP Engineering&  Development
>> FOX Networks Engineering and Operations
>> [e-mail]
>> Phone: [phone]
>> 10201 West Pico Blvd.
>> Los Angeles, CA 90035
>>
>>
>> From: "Mo Zanaty (mzanaty)"<[e-mail]>
>> Date: Tuesday, July 28, 2015 at 11:22 AM
>> To: Michael Speer<[e-mail]>
>> Cc: "[e-mail]"<[e-mail]>, "[e-mail]"<[e-mail]>, "[e-mail]"<[e-mail]>
>> Subject: Re: [payload] [AVTCORE] MMTP vs RTP
>>
>> This is not my work. I just became aware of it in the last meeting. This work would replace RTP itself (RFC 3550) and all RTP payload formats (many specs, e.g. RFC 6184 for H.264). The MMT payload format would be the elementary stream as defined by the codec spec for storage in ISOBMFF containers, augmented with MMT specs and features such as generic packetization / fragmentation.
>>
>> Mo
>>
>>
>> On 7/28/15, 2:05 PM, Michael Speer<[e-mail]>  wrote:
>>
>> Mo,
>>
>> Hi, can you post the RFCs you trying to replace?  In particular, what RTP payload
>> specification are you trying to replace?
>>
>> Cheers,
>> Michael
>>
>>
>> On Tue, Jul 28, 2015 at 9:15 AM, Mo Zanaty (mzanaty)<[e-mail]>  wrote:
>>> I assumed TSVAREA was already aware of this since it was presented there
>>> and will be in their notes. I wanted to bring this to the attention of RTP
>>> folks that may be interested but probably missed this. If there are any
>>> replies here that may be useful for TSV, I will forward. I try to avoid
>>> cross-posting to lists with significantly different topics and subscribers.
>>>
>>> Mo
>>>
>>> On 7/28/15, 12:05 PM, Ali C. Begen (abegen)<[e-mail]>  wrote:
>>> Is not this thread supposed to cc the transport area, too?
>>>
>>> -----Original Message-----
>>> From: avt on behalf of "Mo Zanaty (mzanaty)"
>>> Date: Tuesday, July 28, 2015 at 7:02 PM
>>> To: "[e-mail]", "[e-mail]"
>>> Cc: "[e-mail]"
>>> Subject: [AVTCORE] MMTP vs RTP
>>>
>>>> MMTP (MPEG Media Transport Protocol) aims to replace RTP and MPEG-2 TS
>>>> for media streaming applications, both real-time and non-real-time. It
>>>> integrates FEC, buffering, congestion control and other functions. It was
>>>> presented in TSVAREA in IETF 93. See
>>>> below for the slides and draft.
>>>> https://www.ietf.org/proceedings/93/slides/slides-93-tsvarea-1.pdf
>>>> https://tools.ietf.org/html/draft-bouazizi-tsvwg-mmtp
>>>>
>>>> I found slides 5 and 15 particularly relevant for AVT folks, so inlining
>>>> them.
>>>>
>>>> Why not RTP? (slide 5)
>>>> - Lack of  Multiplexing
>>>>   - One media session per component and without RTP multiplexing, 2 ports
>>>> per session
>>>> - Server Maintenance
>>>>   - RTP Payload Format for every new media codec
>>>>   - Support needs to be added to the media server
>>>> - Coupling of  Presentation and Delivery
>>>>   - RTP carries presentation and synchronization information at the
>>>> transport level
>>>> - Limited support for Non-Real Time Media
>>>>   - Presentations consist of  timed and non-timed media
>>>>   - Need other protocol or countless number of  payload formats to
>>>> support NRT
>>>>
>>>> Why are we here? (slide 15)
>>>> - We want to develop MMTP further in the IETF
>>>> - We want to address the Internet (unicast and Multicast)
>>>> - We want to reuse existing components such as congestion control and
>>>> security
>>>> - A protocol is needed by many SDOs: MPEG, ATSC, 3GPP, DVB, ...
>>>> - Can we revive rmt?
>>>> - Can we start a BoF or a new ad-hoc group?
>>>> - Or can we do an informational RFC?
>>>>
>>>> I think there should be some dialogue on RTP evolution with the MMTP
>>>> folks. Some interesting points are raised in this work, such as generic
>>>> packetization vs. specific RTP payload formats. Perhaps a generic payload
>>>> draft can address this generic packetization
>>>> (i.e. fragmentation and perhaps aggregation) in the absence of a
>>>> specific RTP payload format for the elementary media stream.
>>>>
>>>> Thanks to Gorry for bringing this to my attention.
>>>>
>>>> Mo
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/avt