[AVT] Note from ad-hoc meeting on Rapid Multicast Synchronization

["Ver Steeg, Bill" <VersteB at cisco.com>]

Here are the group's notes from the ad-hoc meeting on Rapid Multicast
Synchronization in Minneapolis on Tuesday. I think we captured the
discussion, but please chime in if we missed something. Many thanks to
the participants, as we had and excellent exchange of ideas.


bvs

------------------------------------------------------------------------
-------------------------------------


In summary, we had a good exposition of the issues at hand. The data
plane looks pretty good. We continue to resolve the control plane
issues, and made good progress. The main outstanding issues revolve
around merging of the two proposed signaling state machines,
particularly around signaling of the burst completion. Two proposals
remain, but we have a much better understanding of the two
methodologies.


The group confirmed that this draft should be generic RTP, and any
transport-specific (e.g. MPEG2TS specific) normative items should be
moved to a separate draft.

Dave introduced some high level requirements that set some scoping for
the discussion. These requirements were presented and refined during the
meeting, and these requirements require more discussion and refinement. 

Detailed discussion points follow:

1- Defining a new RTP payload type format instead of the RTCP
payload-specific feedback message for carrying acceleration-specific
content.

 
The group gained general consensus that the optional "preamble" or
"prime the pump" data that precedes the unicast burst of the original
RTP data should be encapsulated as RTP rather than RTCP. We propose that
we update the draft to reflect this change. This was the subject of
extensive discussion during the review, and we particularly thank Steve
and Jonathan for their thoughts on this matter.

2- Separate the XR report from the current draft.

We need to decide if the XR report is included in this draft or in a
separate draft. Generally agreed is that an XR report containing
detailed information about the burst will be useful. 


3- Bandwidth and buffer size indications in the RMS-R message.


We had extensive discussion of the signaling of the bandwidth and buffer
size information. Consensus was gained that the information was valuable
for the protocol, but clarification and consistent use of the parameter
were needed. We tentatively agreed to define the bandwidth as the
percentage of the stream bandwidth that is available for the unicast
flow. We need to word-smith the draft to be sure this is well conveyed.
It has been tentatively agreed that all parameters are optional (subject
to further tightening  of the protocol ). 

4- Stream termination (BYE message issue).

There was some debate as to when BYE is used. The matter was clouded by
the fact that there are currently two proposals for a mechanism to
terminate the burst. In one scheme, the burst is fully described by the
server and will terminate at the signaled time. In the other scheme, the
RR signals the RS in real time. Concerns have been expressed by some
parties around the stability of the real-time method. 

Based on the discussion, we need to clarify that that BYE is used only
when the RR wants to cancel the whole retransmission RTP/RTCP session
(including the burst) because it is not interested in this stream
anymore. BYE is perfectly fine in this context if there won't be any
(future) retransmissions for this stream. 

To make RS stop bursting, RR still uses the RMS-T message that we
currently have in the draft. This message is optional in one scheme, and
a variant of this message is required in the other scheme. Optionally,
This message carries the seqnum of the first RTP multicast packet if
sent  after the Join.

In either case, RR may signal the seqnum of the first RTP multicast
packet in the XR report as well.

5- Using mpeg2-ts as a use case rather than the main focus in the
document.

Consensus was gained to focus on RTP-generic mechanisms in the normative
part of the document.

There were mixed comments on the inclusion of the
introductory/motivational material in the early section of the draft.
Some reviews felt that it was educational to many users. Others felt
that it cluttered up the document. Once the group comes to consensus,
this will require some editing in the earlier parts of the document.

We are also planning to incorporate some parts of the slides presented
by Dave.

6- Defining a message flow diagram.

The group requested a flow diagram and a "definitions" section in the
document. We will add a flow diagram  and a definitions section. 


7- Security considerations. 

We will work on this issue as we move forward with the draft.

Bill VerSteeg



     - - - - -                              Cisco                            - - - - -         
This e-mail and any attachments may contain information which is confidential, 
proprietary, privileged or otherwise protected by law. The information is solely 
intended for the named addressee (or a person responsible for delivering it to 
the addressee). If you are not the intended recipient of this message, you are 
not authorized to read, print, retain, copy or disseminate this message or any 
part of it. If you have received this e-mail in error, please notify the sender 
immediately by return e-mail and delete it from your computer.

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt