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

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

Hi Roni, 

Snipping off the text we are already in agreement.

> > 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?
> 
> Roni: yes.

Will do.
 
> > 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.
> 
> Roni: So this sentence is not correct, MPEG is not only MPEG 
> 2 for broadcast
> it can be MPEG 4 part 10for video conferencing.

We will incorporate the text YK provided.
  
> > 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.
> 
> Roni: I could not find in the dpcument how you get what is 
> optimal rate to
> start the burst

There is no way to find the optimal burst rate. Optimality varies based on its definition. And pretty much everybody has a different definition. Thus, I don't think we need to get into that discussion much in this document.
  
> > 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.
> 
> Roni: my view is that a message from RR in the case when it 
> gets an RTP flow
> without RMS-I will solve this state.
 
What type of message from 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.
> 
> Roni: Why do you need any parameter for th2 0 and 2 cases. 
> Why not have all
> parameters from RS for the 1 case, this gives the RR the 
> option if to use
> them or not. I am not sure why they are optional if they 
> supply information
> to RR.

Not every implementation uses all this information. Different implementations depend on different fields. See below.
 
> > 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. 
> 
> Roni: When you make something optional, this may mean to a 
> reader that it is
> not needed except in certain cases, but you do not specify 
> the benefit for
> having an optional parameter.

When something is optional in our draft, it means not all implementations need that field. For example, an implementation may never need to use "IGMP join time" field, if it opts to use real-time signaling, i.e., "join now" field when needed.

I don't think we need to discuss the pros and cons of each possible implementation. We provide the common requirements and basic design principles in Section 5. IMO it is pretty sufficient to provide the necessary insight to this problem.
  
> > 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."
> 
> Roni: How does the RS know when the RR will get the message. 
> If I read the
> draft and try to calculate this value as it is written I will 
> not know how
> to calculate this number.

Why not? You should be able to compute a good estimate.
 
> > 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.
> 
> Roni: Clarify this in the text. 

This is already written in Section 7.
   
> > 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.
> 
> Roni: Explain in the text. Is this solution only for 
> declarative or does it
> allow also offer/ answer exchange.

The SDP elements we use in the example are all pre-defined in earlier documents except the "ssli" parameter to be used with "nack". Whether they allow offer/answer model or not, it is already specified in their respective specs.

As for the "ssli" parameter, the same offer/answer model rules apply from RFC 4585. I mentioned this in the revision.

BR,
-acbegen