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

["Ali C. Begen (abegen)" <abegen at cisco.com>]

> Hi,
> I read the draft and have some feedback.

Thanks for the detailed review, Roni.

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

Not that it is impossible, but would not make much sense. Do you think we need rewording here?

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

For virtually all related to broadcast systems. The MPEG specification is quite clear about the timing requirements. There are some low-delay codecs that have quite short buffering requirements, but these tend to be video-conferencing style codecs rather than broadcast style codecs.
 
> 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

Why do you think it must work? It can work, but bad things may happen. 
 
> 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.

There are ways of detecting a good rate for the burst (not the optimal one). And we can discuss them in the session.
 
> 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.

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

Not if carefully engineered.

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

RS can carefully be engineered to allow a minimal overlap. IMO, I think that is better than leaving a gap.

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

If RS terminates proactively without an RMS-T, RR may do retransmission to fill the gap (if any).

> There is also a typo OSN should be SN

OSN is the "original seqeunce number" field (RFC 4588).

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

Not sure if I follow.

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

For mpeg2-ts, we already have a draft:
http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-00.txt

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

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

That means RR does not care about the burst's characteristics. RS may send whatever it decides to.

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

We rather wish to keep it optional. 

> 13. In section 7.1 the length of the feedback message is 
> specified in octet?

Yes, this is already fixed for the next revision.

> Why not use the same semantics of RFC 4585 section 6.1 

That section is pretty similar to ours. Do you want us to include the common fields as well?
 
> 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].

Oh about the length field. Sure, we can do this. 
 
> 14. In section 7.2 " It also includes other useful 
> information for RR." This
> is a general sentence, do you need it?

With future extensions, further useful information can be provided. In the existing message format, join-time, burst-duration, etc are all useful information for RR.
 
> 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.

IGMP join time field must be populated in at least of the RMS-I messages. The rest is optional. This should be less cumbersome if/when we transition to TLV for these fields.

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

Makes sense. But, as it is optional, I believe it is up to the implementation.
 
> 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?

If you think that the one-way delay will cancel out, it fits nicely. It says "join the mcast session X clock ticks or ms after you received this message."

> 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

If you wanna allow a small overlap, the igmp join time should indicate a time a little bit earlier than the the burst will terminate. So, it is related. But, other implementations may not use it and rather prefer "real-time join" signaling.
 
> 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.

The max bitrate RS will use has to be no larger than the max receive bitrate RR indicates in the RMS-R message. The requested message rate may exceed some threshold (like aggregate access network bandwidth) that is known by the RS but not known by the RR.
 
> 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.

This is implementation specific. Related to your earlier question whether to allow a small overlap or leave a gap.

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

It is a 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.

Did not know that. Will fix it.

I hope I have not skipped any question.

BR,
-acbegen
 
> 
> Regards
> Roni Even
>