Subject: [AVT] RE: [AVT]RE:Clarificationson[AVT]Sequenceissuewithdraft-ietf-avt-rtp-selret-04.txt

From: [email-masked]
Date: Mon, 1 Jul 2002 19:04:40 -0500

Jose, 

[Jose]
> in the new draft-ietf-avt-rtp-selret-05.txt (see usage 
> examples section) 3
> scenarios are described to be used with SEL:
> 1) feedback bandwidth is scarce: in this case, it is important to be
> selective about what is reported, because not everything 
> might be reported
> on time.
> 2) feedback scheduling is important: early feedback packets enable the
> timely scheduling of feedback. SEL is needed to distinguish 
> these important
> packets.
> 3) the client-application wants to save feedback bandwidth. For this
> purpose, it sets an application-defined minimum interval between full
> compound regular RTCP packets (please see
> draft-ietf-avt-rtcp-feddback-03.txt, already submitted, shall 
> be annouced
> soon). The goal here is to try to keep the feedback bandwidth 
> consumption as
> low as possible while still enabling low delay feedback (in 
> form of early
> feedback packets) for the duration of the minimum interval. 
> The bottom line
> is that under good link conditions you can keep the feedback 
> bandwidth to a
> maximum defined by the application and under bad conditions 
> you can still
> send feedback in a timely way up to the maximum allowed by the RTCP
> bandwidth. Please see also the examples section in
> draft-ietf-avt-rtp-selret-05.txt.

[David]
I have repeatedly asked you to provide some data showing the performances (numbers) of your scheme in a real-life scenario. I don't think we can draw any conclusions on the applicability of the selective payload with general statements. It is common practice to show the performance of a proposed technology in order to get it included in a standard. Furthermore, this would be useful to implementers to understand whether in their environment they would benefit to use this format or not. 

I cannot comment on version 03 of the feedback profile which is not available

> > [David]
> > I'm sorry to give you a hard time but I must say your answer is
> > confusing me.
> > Your new draft says that the receiver MAY report packet losses of
> > less important packets. Isn't it defeating the very purpose of
> > the selective payload format?
> > Why would you be using this format if the receiver is able to
> > report all the packet loss?

[Jose]
> If the client is able to always report every loss in time so 
> that the server
> is able to use this feedback AND all packets requested arrive 
> always at the
> client before its maximum number of retransmissions is 
> reached, then it
> makes probably no sense to use SEL. But, can you guarantee 
> that these two
> premises always hold? how?

[David]
I think that a real-life feedback channel which is good enough to perform retransmission with the selective payload, would also typically be capable to support a retransmission scheme without the selective payload format.
Please do not take this as a general and negative statement but as a simplified way of exposing what is at stake.

I'm illustrating what I mean here through the example discussed in 
http://www1.ietf.org/mail-archive/working-groups/avt/current/msg01288.html
where you send one I frame and 9 P-frames per second and one RTCP packet per second on the feedback channel.
In this example, the maximum saving of the selective payload is 0.128 kbps. I would argue that if I have a real-life feedback channel which is good enough to allow me to send RTCP packet at a sufficient rate like every second, in a real-life environment I could afford to send an additional 0.128 kbps over this channel.

Again, all I'm asking is some realistic data which would show where the use of the selective format would make a difference.

[David]
> > Maybe the answer is in your statement that the receiver should
> > report the loss of important packets before less important
> > packets. But what does 'reported before' mean here? This is not
> > in your draft. Again, some actual measurement numbers would help
> > to validate your concepts.
> 

[Jose]
> If feedback bandwidth is scarce you might limit the feedback 
> bandwidth to
> the important packets. If you have fixed the interval between feedback
> messages to accomodate to the RTCP bandwidth, then you get to 
> report, say 16
> RTP packet losses in one RTCP message. If there's still space in the
> feedback messages then report also the other losses. Remember 
> that the 1
> (one) general NACK message can report a maximum of 16 lost 
> RTP packets.  If
> you need to report more then you would have to add a new RR 
> for every new
> feedback NACK message, e.g. if you include two RRs in one 
> RTCP message this
> would approx. double the interval between RTCP messages. This 
> might be too
> late for the packets being reported.

[David]
I was not aware that the RTCP NACK packet was limited to report 17 RTP packets.  This was not in earlier versions of the draft based on which we have implemented this profile. I'd like to see the rationale for introducing this change. An implementation does not have any problem with having multiple PID, BLP fields per RTCP NACK since the number of such fields can be derived from the length of the RTCP header. I believe that this limitation should be removed from the draft since it is unnecessary overhead.

[Jose]
> 1.-can you guarantee that there will be always enough RTCP 
> bandwidth for
> every application to report all losses? how?
> 2.-can you guarantee that in applications like MPEG4, the 
> maximum number of
> important packets will reach the client? You need to be 
> selective to do
> this. You may want to skip the retransmission of less 
> important packets in
> favour of those for more important packets and so keep the quality as
> constant as possible. If not so, how would you do it? what is 
> your proposal
> to reach a similar effect?

[David] 
Please look at example above

> > [David]
> > I'm really perplexed after reading your last statement. How can
> > you avoid "interactions between an encoder and an RTP module" to
> > perform selective retransmission.
> > Don't you need the encoder to
> > tell the RTP sender which packets are important in order to
> > signal this in your selective payload?

[Jose]
> Yes, you do. What I mean is that this doesn't have to be done 
> everytime you
> receive a request on a packet and want to check the 
> importance of it. If you
> encapsulate it once in RTP with SEL, then you just have to look in the
> header to have the information of the packet.

[David]
I disagree. There's no interaction between the RTP sender and the encoder when a packet request is received. When a packet is sent for the first time and stored for possible retransmission, you just need to store a flag indicating the packet priority. The selective payload format does not simplify the interactions between the encoder and the RTP sender in any way.

David. 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt