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

From: José Rey <[email-masked]>
Date: Mon, 01 Jul 2002 17:09:59 +0200

Hi David and all,

The questions from David make me think there's a little confusion. I will
try to explain:

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.

I hope this clarifies.

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im Auftrag von
> [email-masked]
> Gesendet: Freitag, 28. Juni 2002 18:26
> An: [email-masked]; [email-masked]
> Betreff: RE:
> [AVT]RE:Clarificationson[AVT]Sequenceissuewithdraft-ietf-avt-rtp-selret-
> 04.txt
>
>
>
>
> 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?
>

Still thinking about 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?

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?

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

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.

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

Of course, I never meant the contrary. But it may still be limited by the
backchannel link and not enough to report all losses, e.g. a satellite link.
In this case it is useful to have some means to differentiate packets.

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

David,

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?

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

[David]
> Don't you need the encoder to
> tell the RTP sender which packets are important in order to
> signal this in your selective payload?

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.

Jose

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

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