Subject: [AVT] Comments from RAMS WGLC

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 23 Dec 2009 14:01:09 -0800

I believe WGLC ended today. Here are the comments received so far and the changes the WG seems to have agreed on for the revision. Please review and let us know if there are comments we missed. 

Thanks,
-acbegen

----

Outstanding Issues:

-- SSRC signaling and handling multi-stream RTP sessions

This will be discussed in a separate email. 

Resolved Issues:

-- Explanation of the existence of two RTP sessions, handling of multi-stream RTP sessions, etc.

We will put new text in the introduction. Also present MPEG video applications as a use case.

-- Clear up the detailed text on page 7 

We will remove the part starting from "The packet(s) carrying the Reference Information are sent..." to the end of the paragraph.

-- Explain where RAMS-T, RTCP BYE are sent in the unicast session

These go to the RTCP port of the retransmission session (burst source). A secondary BYE (if needed) is sent to the RTCP port of the primary SSM session (feedback target).

-- Explain wrapping in MSN field in RAMS-I

We will add a note, though wrapping should not occur in RAMS since the seqnum is reset with every new request.

-- New definition for earliest multicast join time field

Earliest Multicast Join Time (32 bits):  Optional TLV element that specifies the delta time (in ms) between the arrival of the first RTP packet in the retransmission session and the earliest time instant when RTP_Rx SHOULD send an SFGMP Join message to join the primary multicast session. A zero value in this field means that RTP_Rx can join the primary multicast session right away. Note that the first RTP packet in the ret session could be a burst packet or a preamble packet but cannot be an RTCP packet.

-- New definition for the burst duration field

Burst Duration (32 bits):  Optional TLV element that denotes the duration of the burst, i.e., the delta difference between the first and the last burst packet, that RS is planning to send (in ms). In the absence of additional stimulus, RS will send a burst of this duration.  However, the burst duration may be modified by subsequent events, including changes in the primary multicast stream and reception of RAMS-T messages.

-- Explain the handling of ext seqnums in section 7.4

These are still per receiver. Everybody reports their own extended seqnum values. No difference from 3550.

-- Specify the normative references for signaling 

We will do this in the SDP section (not the examples section).

-- Explain whether "rams-updates" attribute is session or media level.

It is media level. Will add this to the SDP section.

-- Note on little/big-endian usage in TLV elements.

We will use the rules from 3550 and mention this explicitly in the draft.

-- The announcement of media sender SSRCs in the SDPs

This will be optional (but recommended if possible). 

-- Remove section 10

Section 10 will be removed.

-- Put a normative reference to Port Mapping proposal in Section 9

That discussion is not specific to RAMS, so it will move forward in a separate document.

-- Size of Max Receive Bitrate field in RAMS-R (and the answer in RAMS-I)

These will be converted to 64 bits.

-- Field alignment in TLVs and update the definition for TLV length

We will fix this issue with introducing reserved bits. This is to align TVLs to a word boundary. 

-- Retransmission for lost burst packets

This is optional for both the receiver and server. The receiver may ask for it at any time and the server may or may not respond to it. If it does, it may have to send an updated RAMS-I message.

-- Join-time information

The receiver SHOULD adhere to the join time signaled by the server. The receiver follows the most recently received information. The server may update the value but the receiver should always obey to the server. If there is no join-time info sent by the server, the receiver will decide when to join.

-- Clarify the definition of Reference Information

Not all parts of the Reference Information will be repeated periodically (E.g., I-frames do repeat but they are not the same I-frames). We need to fix the defition. 

-- Accept/reject rules for the retransmission server

The server MUST (not SHOULD) obey to any reqs specified by the receiver. Input from Eric F.'s email from Dec. 10.

-- Sender reports in the unicast session

To allow rapid synchronization among the RTP streams during the burst, a sender report is needed to be sent in this unicast session reflecting the synchronization info from the primary session. However, instead of using sender reports, we will recommend the header-ext approach proposed in draft-ietf-avt-rapid-rtp-sync. Note that sender reports are still to be sent in the unicast session.

-- Congestion control considerations during the burst

We are expecting input text from Magnus.

-- Defining a response code that says the request was denied due to policy

Will be added to registry.

-- Revise the max/min buffer reqs text in RAMS-R

New text should explain why we use ms instead of bytes. Also add the following.

If specified, the amount of backfill that will be provided by the unicast burst and any payload-specific information MUST NOT be larger (or smaller) than this value since it may cause buffer overflows (or underruns) at RTP_Rx.

-- Sending a RAMS-I at the start of the burst

There were comments in the mailing list about the timing of RAMS-I. We used the term "early enough" in the text but that was not very clear. In practice, RAMS-I needs to be received by the receiver at the beginning of the burst so that the receiver can decide whether it is missing any burst packets or not. If there are missing packets, the client may decide to bail out from the burst and join the SSM session right away. So, as suggested, the server SHOULD send an RAMS-I at the beginning of the burst. As usual, RAMS-I updates may follow later during the burst with updated/revised information.

-- Ability for receivers to ask only for the preamble or for servers to send only the preamble

We will define a new RAMS-R TLV element that requests only the preamble from the server. We will also define a new 500-level response code for the server: Only preamble will be sent (no burst).