Re: [AVT] WGLC for draft-ietf-avt-rapid-acquisition-for-rtp-05.txt

[Colin Perkins <[e-mail]>]

Hi Ali,

One comment at the end - the rest looks fine.
Colin



On 22 Dec 2009, at 13:35, Ali C. Begen (abegen) wrote:

> Hi Colin,
>
>> Several IPR disclosures have been filed relating to this draft:
>>
>> https://datatracker.ietf.org/ipr/990/
>> https://datatracker.ietf.org/ipr/1024/
>> https://datatracker.ietf.org/ipr/1025/
>> https://datatracker.ietf.org/ipr/1128/
>> https://datatracker.ietf.org/ipr/1200/
>>
>> Some of these offer a "Reasonable and Non-Discriminatory License to
>> All Implementers with Possible Royalty/Fee" but provide few details;
>> others offer a more clearly defined non-assert. Could the chairs
>> please seek clarity on the RAND terms before requesting publication  
>> of
>> this draft as a proposed standard RFC? I do not think it appropriate
>> to publish this draft subject to the current IPR licensing  
>> requirements.
>
> I will let the chairs handle this.
>
>> At a high level, the draft would benefit from an explicit discussion
>> of how many RTP sessions are used, whether the burst/retransmission
>> flows form a separate RTP session to the multicast data, or if  
>> they're
>> part of the same RTP session as the multicast data. This would also
>> clarify how the SSRC space is to be managed, which is still not clear
>> from the draft. The draft also needs to be clear on its applicability
>> to SSM RTP sessions where the source is using multiple SSRCs, to
>> scenarios where multiple RTP sessions are being acquired, and to non-
>> SSM scenarios. The relationship between RAMS, RTP sessions, and RTP
>> SSRCs is generally not clear, and I think will be problematic unless
>> clarified.
>
> Yes, we will take this into account in the revision.
>
>>
>> Technical details:
>>
>> - Bullet point 2 on page 18 suggests that "It is RECOMMENDED to
>> include a sender report with the RAMS-I message in the same compound
>> RTCP packet" and suggests that this is useful for rapid
>> synchronisation. As has been discussed off-line, that doesn't work
>> since the Burst Source doesn't have access to the NTP-format clock
>> used by the media sender.
>
> Right, this will be fixed.
>
>> - Bullet point 8 on page 20: need to clarify is the RAMS-T sent to  
>> the
>> FT, or the burst source?
>
> It goes to the RTCP port of the retransmission session (feedback  
> target for the ret session, which should be the burst source in our  
> text).
>
>> - Bullet point 9 on page 20: need to clarify is the RTCP BYE send to
>> the FT, or to the burst source?
>
> This also goes 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).
>
>> - Section 7.2 the Min and Max RAMS Buffer Fill Requirements are
>> specified in milliseconds, with 32 bits. If I calculate it right,  
>> that
>> gives a maximum buffer requirement of approximately 7 weeks. That
>> might be too much?
>
> :) 16 bits is 64 seconds only.
>
>> - Section 7.2 also specifies the Max Receive Bitrate as a 32 bit
>> number of bits per second. While they're not used for IPTV, there are
>> several RTP implementations that are pushing that limit. For future
>> proofing, it might be appropriate to specify this limit in kbps,
>> rather than bps. Similar for Max Transmit Bitrate in section 7.3.
>
> We will rather go for 64 bits as suggested earlier.
>
>> - Section 7.3: specify wrapping behaviour of the MSN field.
>
> Will do, though wrapping should not occur in RAMS since the seqnum  
> is reset with every new request.
>
>> - Section 7.3: The Earliest Multicast Join Time is specified in terms
>> of a delay from the arrival of the RAMS-I at the receiver, yet the
>> burst source cannot know when the RAMS-I will arrive.
>
> Good point. We can revise it to:
>
> 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.
>
>> - Section 7.3: Burst Duration is specified in "RTP ticks". Which RTP
>> clock is used? How is it signalled?
>
> This could be taken from the SDP but this will be confusing when  
> there are SSRC-muxed streams. So, what about:
>
> 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.
>
>> - Section 7.4 specifies the use of an extended RTP sequence number.
>> It's not clear if this is necessary, but if it is, the semantics of
>> the extension need to be defined (the RFC 3550 definition is per
>> receiver, but these are going to the burst source which deals with
>> multiple receivers).
>
> They are still per receiver. Everybody reports their own extended  
> seqnum values.
>
>> - The SDP examples in section 8.2 appear to contain a large number of
>> normative requirements. The draft needs to clearly state the  
>> normative requirements of the signalling, separate from the examples.
>
> Only RFC 5576 won't be normative in the revision. The rest is needed  
> as normative.

Sure, but not in a section entitled "Examples" :-)

>> - I do not believe the NAT considerations in Section 9 are sufficient
>> for interoperability. At minimum, a normative reference to draft- 
>> begen-
>> avt-ports-for-ucast-mcast-rtp is needed; preferably the main RAMS
>> draft needs to consider NAT traversal seriously.
>
> Right.
>
>>
>> Editorial comments:
>>
>> - The introduction would be clearer if a motivating example were  
>> given
>> (e.g. the use of multicast MPEG video, where one must wait for the I-
>> frame to begin decoding).
>
> We can do that.
>
>> - The draft uses the term "single-source multicast (SSM)" in several
>> places; it should use "source-specific multicast".
>
> We just wanted to be RTCPSSM draft compatible :) will fix.
>
>> - The summary on page 7 is perhaps overly detailed, and it certainly
>> shouldn't make normative requirements on implementations. It might be
>> appropriate to remove it, and rely on the summary in section 6.
>
> I am not sure which part is overly detailed. Can you elaborate?

In the first paragraph on page 7, I suggest deleting everything from  
"The packet(s) carrying the Reference Information are sent..." to the  
end of the paragraph.

>> - Section 6.2 clearly defines the Feedback Target, the Burst Source,
>> and the Retransmission Source. The remainder of the draft then
>> proceeds to confuse these by using the single term Retransmission
>> Server instead. I recommend that the logical roles of Feedback  
>> Target,
>> Burst Source, and Retransmission Source are uses throughout, to avoid
>> confusion on which data is sent where (Figure 3 is especially  
>> unclear,
>> but much of the text also suffers from the problem).
>
> We will try to make these clear in the revision.
>
> Let me know if you are OK with these changes.
>
> Thanks,
> -acbegen
>
>> --
>> Colin Perkins
>> http://csperkins.org/
>>
>>
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt



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