Subject: [AVT] Answers about draft-ietf-avt-rtp-selret-04.txt

From: José Rey <[email-masked]>
Date: Thu, 06 Jun 2002 18:23:55 +0200

hi David, Go and all,

please see my comments in-line

David Leon wrote:
> What rtp-selret proposes would be more correctly named "selective
> request" instead of selective retransmission, i.e. the receiver
> requests only some of the lost packets.

Selret proposes a mechanism at RTP level to enable selective retransmission
requests AND selective retransmissions. The whole is referenced by the more
general term selective retransmission.

Selective retransmission requests are issued by the RTP client.

Selective retransmissions  are issued by the RTP server. Furthermore, as
some packets at the server might become important as they, e.g. become
older, approximate its last retransmission, etc,...the RTP server has the
chance to change the priority of the packets at RTP level. Thus dynamically
adjusting itself to bandwidth conditions. This could be used by scheduling
and rate control algorithms to handle RTP packets, without having to look
inside the payload, thus saving processing overhead.

As for the questions David listed:

> There are therefore two questions that have to be answered:
> 1)Should two approaches (same or separate session) be allowed or
> only one should be mandated?
> 2)Should a payload format for "selective request" be part of an
> RTP retransmission document and if yes should it be required or optional?
>
> As far as 1) is concerned, the drafts will be resubmitted with
> applicability statements which I think will help discuss the
> trade-off between as you wrote allowing multiple approaches and
> fostering interoperability.

this is correct.
>
> As far as 2) is concerned, I think it needs first of all to be
> demonstated  the efficiency of the selective payload format. As I
> wrote above, the purpose is to provide selective requests and not
> selective retransmission.
> Some of the questions which should be answered are:
> *for which type of applications does it make sense?
> *at which bit rate, packet loss rate and distribution?
> *what is the bandwidth saving of selective request vs requesting
> every packet in the RTCP session?
> *what is the bandwidth added overhead of using the selective
> retransmission in the RTP session?

As for the item 2)

> *what is the penalty of requesting only some of the lost packets
> vs requesting all of them?

For all those appplications in which data has different importance levels,
for example: MPEG4.

> *at which bit rate, packet loss rate and distribution?

Depends on the application. General statements on this are of little use.
SEL is designed to be adaptive. Depending on the received quality (lost
packets, throughput) of an initial setting, the server can mark more or less
packets as being important. This requires some intelligent scheduling
algorithm at the server.

> *what is the bandwidth saving of selective request vs requesting
> every packet in the RTCP session?

The answer to this depends on:

- the number of the packets marked as important.
- the RTCP timing rules. This is work in progress:
draft-ietf-avt-rtcp-feedback-02.txt.

> *what is the bandwidth added overhead of using the selective
> retransmission in the RTP session?

Variable. Depends on the payload size. Let us suppose a MPEG4 video
application under the following constraints and doing pessimistic
assumptions:

- we always use 4 byte SEL header (with full SN instead of DeltaSN)
- we have 10 frames per second: 1 I-frame and 9 P-frames
- we add the SEL header to all packets
- the RTP packets are ~400 bytes long (incl. IP/UDP/RTP headers).

This gives a total overhead of 4/400=1%, under pessimistic assumptions.

> *what is the penalty of requesting only some of the lost packets
> vs requesting all of them?

Already answered above: "The answer to this depends on:...."

cheers,

José

> David.
>
>
> >
> > So, what is the current path to choosing a single approach
> > and sticking to
> > it?
> >
> > Go
> > ---------- Forwarded message ----------
> > Date: Thu, 25 Apr 2002 16:51:54 -0500
> > From: "[email-masked]" <[email-masked]>
> > To: "[email-masked]" <[email-masked]>,
> >      "[email-masked]" <[email-masked]>
> > Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
> > <[email-masked]>,
> >      "[email-masked]" <[email-masked]>
> > Subject: [AVT] RE: Retransmission Format
> >
> > Bill,
> >
> > Thanks for your comments.
> > At the last AVT meeting, we proposed to merge the two drafts
> > within a single draft. However, it was felt that it would be
> > more clear to keep the two approaches into two separate
> > documents. Both drafts will be resubmitted with an
> > applicablity statement.
> > As far as the 4-byte alignement is concerned, we have chosen
> > to minimise the overhead. This can be worthwile when the RTP
> > header is compressed and the payload is small.
> > It is hard to tell how many extension bits it is reasonable
> > to define. However, provided that one extension bit is
> > defined I guess we are safe as any future extension may
> > define its own extension bit.
> >
> > Regards, David.
> >
> > > -----Original Message-----
> > > From: ext Bill Foster [mailto:[email-masked]]
> > > Sent: Thursday, April 25, 2002 4:12 PM
> > > To: Leon David (NRC/Dallas); Varsa Viktor (NRC/Dallas)
> > > Cc: Naoshad Mehta; [email-masked]; [email-masked]
> > > Subject: Retransmission Format
> > >
> > >
> > > David, Victor:
> > >
> > > The retransmission format you have suggested in
> > > draft-ietf-avt-rtp-retransmission-00.txt has an odd number
> > of bytes -
> > > rather than sitting on the normal 4 byte boundary. In
> > > addition, there may
> > > be some need in the future for more than one bit for
> > > extensions. I would
> > > like to see that remaining byte left as reserved and the
> > > retransmission
> > > header end at the 4 byte boundary. This will make life easier
> > > for some
> > > implementations w.r.t. development and performance and allows
> > > for potential
> > > extensions later on.
> > >
> > > The format is almost the same as in
> > > draft-ietf-avt-rtp-selret-03.txt. Is
> > > there an intent to merge the formats? The same comment
> > > applies to that
> > > draft. It appears that the formats are pretty much the same
> > > anyway except
> > > for the meaning of X versus E bit. In either case, I would
> > > like to see
> > > headers end on a four byte boundary (preferably one format
> > > even though the
> > > drafts appear to be addressing slightly different applications).
> > >
> > > Bill
> > > -----------------------------
> > > Bill Foster
> > > Phone: (250) 758-9418
> > > Fax:     (781) 998-6492
> > >
> > >
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> 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

---

From: [email-masked]
Date: Tue, 11 Jun 2002 17:48:19 -0500

Jose and all, 

Below are some comments on your answers about the efficiency of the selective payload format

> > *for which type of applications does it make sense?

[Jose]
> For all those appplications in which data has different 

[David]
So it needs to be emphasised that for many applications such as audio streaming, this payload format should not be considered at all.

> > *at which bit rate, packet loss rate and distribution?

[Jose]
> packets as being important. This requires some intelligent scheduling

[David]
I really think there needs to be shown some performance evaluation data (for example PSNR measurements in a realistic scenario) in order to evaluate the usefulness of this payload.  

In order to understand the selective payload format better, let's assume that RTCP receiver reports are sent every second. There are 2 cases: 
*The receiver does not have any packet loss to report and does not send a NACK in the RTCP packet whether the selective payload is used or not.
*The receiver has packet loss to report. If the selective payload format is used, the NACK will be sent only if the receiver knows that one of the lost packets was chosen as a high priority packet whereas if no selective payload format is used, the NACK packet will be sent in any case.
It follows that the selective payload format can at best save sending a NACK at every report interval. 

If we assume that in the video example that you have given (10 frames per second), the RTCP report interval is one second, the NACK packet size would then be 16 bytes. Therefore, the selective payload format would save at best 16 bytes (assuming that a NACK packet is always sent if the selective payload is not used and never sent if selective payload is used) per second of RTCP data, that is 0.128 kbps.
In addition, this maximum 0.128 kbps saving comes at the expense of having the sender know only partially the packet loss at the sender.

The selective payload format does not save any RTP bandwidth, as selective retransmission of RTP packets by the sender can be achieved whether or not the selective payload is used.     

> > every packet in the RTCP session?

[Jose]
> draft-ietf-avt-rtcp-feedback-02.txt.

[David] 
Refer to the above comment.

> > retransmission in the RTP session?

[Jose]

> This gives a total overhead of 4/400=1%, under pessimistic 

[David]
In this example the overhead of the selective payload is 40 bytes per second in the RTP session. 
If we assume as above that the RTCP report interval is one second, the saving of the payload format is 16 bytes per second in the RTCP session.
Use of the selective payload in a streaming session therefore means:
*a 40 bytes per second increase in the server-client direction
*a maximum 16 bytes per second decrease in the client-server direction

> > vs requesting all of them?

[Jose]
> Already answered above: "The answer to this depends on:...."

[David]
Let me illustrate what the penalty of requesting only some of the packets could be. In your above example, if the selective payload format is used and the only packet loss is a P frame, this packet will not be retransmitted.
On the other hand, if no selective payload format is used, the sender will be able to know about the loss of this P frame. It may then decide to retransmit the packet and adapt to a lower rate. 

David.