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

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

Ali,
Inline
Thanks
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen at cisco.com] 
Sent: Friday, March 13, 2009 5:15 PM
To: Roni Even; IETF AVT WG
Subject: RE: Review of draft-versteeg-avt-rapid-synchronization-for-rtp-02

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

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

Roni: When you write an IETF document it should work 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.

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

Roni: I agree so write it.

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

Roni: In this specific case it will happen according to the document because
the RR wanted to get a specific packet. I think that the least is to explain
this case or allow for RR to ask the RS to wait for RMS-T in the RMS-R.

> There is also a typo OSN should be SN

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

Roni: so write "Original Sequence Number (OSN)"

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

> 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

Roni: I read this draft and can give separate feedback. 

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

Roni: Clarify in the text

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

Roni: See my comment on 4 above

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

Roni: OK
 
> 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.

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.

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

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

Roni: Explain this is the text.
 
> 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. 


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

Roni: See my comment on your response above.

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

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