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

[Colin Perkins <[e-mail]>]

On 23 Nov 2009, at 03:12, Tom Taylor wrote:
> This is to announce Working Group Last Call for
>
> http://www.ietf.org/id/draft-ietf-avt-rapid-acquisition-for-rtp-05.txt
>
> Given the amount of interest in the topic, the Last Call period will  
> be four weeks, until 23 December 2009 assuming comments can be  
> resolved.


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.



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.



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.

- Bullet point 8 on page 20: need to clarify is the RAMS-T sent to the  
FT, or the burst source?

- Bullet point 9 on page 20: need to clarify is the RTCP BYE send to  
the FT, or to the burst source?

- 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?

- 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.

- Section 7.3: specify wrapping behaviour of the MSN field.

- 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.

- Section 7.3: Burst Duration is specified in "RTP ticks". Which RTP  
clock is used? How is it signalled?

- 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).

- 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.

- 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.



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).

- The draft uses the term "single-source multicast (SSM)" in several  
places; it should use "source-specific multicast".

- 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.

- 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).

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