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

From: Colin Perkins <[email-masked]>
Date: Mon, 21 Dec 2009 18:32:07 +0000

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/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 22 Dec 2009 05:35:56 -0800

Hi Colin,

> to publish this draft subject to the current IPR licensing requirements.

I will let the chairs handle this.

> SSRCs is generally not clear, and I think will be problematic unless

Yes, we will take this into account in the revision.
 
> 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

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).
 
> 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).
 
> gives a maximum buffer requirement of approximately 7 weeks. That

:) 16 bits is 64 seconds only.
 
> 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.
 
> 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.
 
> 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.
 
> receiver, but these are going to the burst source which deals with

They are still per receiver. Everybody reports their own extended seqnum values.
 
> requirements of the signalling, separate from the examples.

Only RFC 5576 won't be normative in the revision. The rest is needed as normative. 
 
> draft needs to consider NAT traversal seriously.

Right.

> frame to begin decoding).

We can do that.
 
> places; it should use "source-specific multicast".

We just wanted to be RTCPSSM draft compatible :) will fix.
 
> appropriate to remove it, and rely on the summary in section 6.

I am not sure which part is overly detailed. Can you elaborate?
 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Dec 2009 14:14:27 +0000

Hi Ali,

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

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

> 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).
>
> 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).
>
> 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.
>
> 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.
>
>> normative requirements. The draft needs to clearly state the  
>> normative requirements of the signalling, separate from the examples.
>

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

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

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