[AVT] Review of draft-versteeg-avt-rapid-synchronization-for-rtp-02

["Roni Even" <ron.even.tlv at gmail.com>]

Hi,
I read the draft and have some feedback.

1. In section 1 " The feedback target starts a unicast retransmission RTP
session and sends the Reference Information to the receiver over that
session.  If there is spare bandwidth, the feedback target may also burst
the Reference Information at a faster than natural rate." 

I was under the impression that spare bandwidth is required. Are you
suggesting here that the RR may use the unicast stream for the whole time if
no spare bandwidth is available.

2. At the end of section 4 " For example, MPEG  decoders require a
significant amount of content to be available in the decoder buffers prior
to starting to decode the content." 
Is this true for all MPEG codecs and all encoding profiles.

3. In section 5 "Rapid synchronization is an optimization of a system that
must continue to work correctly whether or not the optimization is
effective, or even fails due to lost control messages, congestion, or other
problems.  This is fundamental to the overall design requirements
surrounding the protocol definition and to the resource management schemes
to be employed  together with the protocol (e.g., QoS machinery, server load
management, etc).  In particular, the system needs operate within a number
of constraints." 

Do you require resource management scheme as part of the solution, I think
that the solution MUST work also on the free Internet

4. In section 5 " Similarly, using a TCP (or TCP-like) approach with a 3-way
handshake and slow-start  to avoid inducing congestion would defeat the
purpose of attempting rapid synchronization in the first place by
introducing many RTTs of delay." 
I think that calls for some mechanism to find the optimal rate for starting
the burst. I think this is discussed in the Peilin draft.

5. In 6.2 editor note. My view is that having the entities physically
co-located in this draft make sense and the text should state it and suggest
that physical decomposition is for futher study.

6. In 6.2 step 6 " RS may know when it needs to stop the unicast burst based
on the burst parameters , or RR may explicitly let RS know the sequence
number of the first RTP packet it received from the multicast session, or RR
may request RS to terminate the burst immediately."

I think that if the RS stops the burst by his own decision may cause a gap.
The question is what is better to have a gap and fill it using retransmit or
having both unicast and multicast simultaneously for a short time. Gap WILL
always require action while overlap MAY cause congestion loss.

7. In the same step 6 " In the latter case, RR SHALL include the sequence
number of the first RTP packet received in the SSM session in the RMS-T
message, and RS SHOULD terminate the burst after it sends  the RTP burst
packet whose OSN field in the RTP retransmission payload header matches this
number minus one."

I am wondering what happens if the RS decided to stop the burst before
receiving RMS-T. The RR may never receive the packet in with the requested
SN and may wait or start request for retransmission.

There is also a typo OSN should be SN

8. In 6.4 "In the case RR starts receiving an RTP burst but it does not
receive a corresponding RMS-I message  within a reasonable amount of time,
RR MAY either discard the burst data and stop the burst by sending an RTCP
BYE message to RS, or decide not to interrupt the RTP burst and be prepared
to join the primary multicast session at an appropriate time it determines
or indicated in a subsequent RMS-I message."

I think that since another RMS-I is not mandatory this will be a good reason
to have a rate adaption message from RR to RS as defined in the Peilin
draft.

9. In section 7 "Specific payload formats are not defined in this document,
but a framework is presented that allows payload-specific information to be
included in the exchange ."
I assume this is future text, look also at RFC 4585 application layer
message.

10. Editorial comment on section 7.1 - 7.3, maybe use the format for
specifying messages in RFC 4585 section 6.3

11. In section 7.1 you have the MIN RMS and Max RMS buffer fill explaining
what the RS behavior should be if specified but there is no text that
explains what should the RS do if they are not specified.

12. In section 7.1 the same comment on max bit rate but here I think that
the RR should always send it to allow for a optimal burst speed.

13. In section 7.1 the length of the feedback message is specified in octet?
Why not use the same semantics of RFC 4585 section 6.1 

Length: 16 bits
      The length of this packet in 32-bit words minus one, including the
      header and any padding.  This is in line with the definition of
      the length field used in RTCP sender and receiver reports [3].

14. In section 7.2 " It also includes other useful information for RR." This
is a general sentence, do you need it?

15. in Section 7.2 response parameter. If the value is 1 does it require
that existence of the following optional parameters which are not needed for
value 0 or 2.

16. In section 7.2 response parameter. If the value is 2 I assume that there
is no reason to retransmit a message with this value since the previous
condition for join may not exist. (this is an assumption since you do not
explain the motivation to send this value)

17. In section 7.2 "Earliest IGMP Join Time (32 bits):  Time difference
between the arrival of the RMS-I message  and the earliest time instant when
RR could join the new multicast session (in RTP clock ticks)" How does the
RS know when "the arrival" will happen?

18. In section 7.2 what is the use of Rapid Synchronization Duration, what
happens if not specified and is there any relation to IGMP join time

19. In Section 7.2 what is the relation between Mac Burst Rate and the max
receive bit rate in RMS-R. Is this value the maximum that the RS can send or
is it the maximum he will use.

20. In section 7.3 there are two options when to send the RMS-T message. Any
recommendation or motivation to use one or the other.

21. The example in 8.2 is a bit confusing to me. I see that this is an SDP
from the multicast source. Is this an offer, and answer or is it an
declarative SDP. 

22. On the syntax of the example in 8.2 why you have the video as receive
only if this SDP is from the multicast source. Also there should be one fmt
line and the parameters should be separated by semi-colon.


Regards
Roni Even