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

From: [email-masked]
Date: Fri, 28 Jun 2002 11:25:37 -0500

Jose,

[Jose] 
> (note that not all questions are replied, I'll do it as time allows)

[David]
Thanks. I'll be waiting for your other comments. In the meantime, my answers below.

> > [David]
> > You are sending in every packet a variable which is incrementing
> > by one for every packet retransmission you send. You may call
> > this variable retransmission counter or retransmission sequence
> > number as you prefer.
> >
> > I find it helpful to refer to it as a retransmission sequence
> > number since this is the sequence number that you would send in
> > the retransmission stream if you were sending it as a separate
> > stream. Therefore, your proposal is in essence to encapsulate
> > this retransmission sequence number space (or retransmission
> > counter) in the RTP stream which is equivalent to sending two
> > sequence number spaces per RTP stream.
> >
> >

[Jose]

> Let's just call them RTP SN and RTX counter.

[David]

OK. The name does not matter as long as the concept is clear.

> > [David]
> > Am I mistaken to say that if you retransmit a packet twice, this
> > packet would carry 5 payload type fields?
> >
> 

[Jose]
> This is NOT correct.
> 
> The correct PT sequence for the second retransmision of a 
> packet would be:
> 
> RTP header - PT=RTX | RTX header1 - PT=RTX | RTX header2 - 
> PT=RTXcounter |
> RTX counter - PT=media, e.g. MPEG4 video|
> 
> Total 4 PT fields
> 
> and for the third:
> 
> RTP header - PT=RTX | RTX header1 - PT=RTX | RTX header2 - 
> PT=RTX |  RTX
> header3 - PT=RTXcounter |RTX counter - PT=media, e.g. MPEG4 video|
> 
> Total 5 PT fields.

[David]
Thanks for the clarification. When you add your new payload format to the draft, it would be helpful to have these examples.

> 
> > [David]
> > What do you mean when you say "this new 2-byte payload format
> > would be defined separately" ?
> 
> This means as a third payload format in the draft.

[David]
OK. Are you going to add it?

[Jose]
> There's been a change in the SEL payload format. In previous 
> versions SEL
> wouldn't allow to report the loss of packets not marked as 
> important. This
> has changed. In draft-ietf-avt-rtp-rtp-selret-05.txt it is 
> allowed to send
> feedback on every lost packet as long as there's enough RTCP feedback
> bandwidth. The only requirement is the losses of important packets are
> reported BEFORE the losses of other less important packets. 
> This ensures a
> quality as constant as possible at the receiver, that is 
> WITHOUT abrupt
> changes, because the maximum number of important packets (for 
> the given
> bandwidth) reached the receiver.
> 

[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?
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]
> Therefore, if the RTCP feedback bandwidth is limited you can 
> ensure by using
> SEL that the maximum number of important losses will be reported (and
> eventually be retransmitted and reach the client) as allowed 
> by the current
> RTCP bandwidth and forward link conditions.

[David]
What does current RTCP bandwidth mean? Isn't the RTCP bandwidth set (for example with SDP) at the beginning of the session and constant during the session?

[Jose]
> Two observations about SEL:
> 1.-in a retransmission scheme without such selective 
> mechanism it happens
> that the loss of less important packets may be reported 
> before the ones of
> the more important, as the client doesn't know which packets are more
> important than others. This has as a consequence that when receiving
> feedback for the more important (which would have come 
> earlier if using
> SEL), it may already be too late. This means that the 
> receiver would have
> variable reception quality, with abrupt changes. SEL enables this
> selectivity at RTP level.

[David]
I'm not getting your point. If no selective payload is used, the receiver reports all the packet loss at the same time. This is explained in the rtp-retransmission draft. 
Here again, we would need some numbers to understand your scheme.

> 2.-what's more, the importance of the packets doesn't have to be fixed
> apriori. For example, if the server sees that the client has enough
> bandwidth to send more retransmission of important packets 
> then it marks
> more RTP packets as important (e.g. the I frames and 2 
> P-frames after every
> I-frame). This allows the server to adaptively provide the 
> client with the
> best video quality.
> While it can be argued that this last item (2) is possible also at
> application level, the benefit of SEL is that everything 
> remains at the
> transport level, avoiding interactions with the application 
> who know about
> the importance of each packet, e.g. the encoder. The 
> processing is thus
> minimised.

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

David.

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