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

["Ali C. Begen (abegen)" <[e-mail]>]

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