[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] RE: Answers about draft-ietf-avt-rtp-selret-04.txt
- To: <avt@ietf.org>, <rey@panasonic.de>
- Subject: [AVT] RE: Answers about draft-ietf-avt-rtp-selret-04.txt
- From: David.Leon@nokia.com
- Date: Tue, 11 Jun 2002 17:48:19 -0500
- List-Id: Audio/Video Transport Working Group <avt.ietf.org>
- Sender: avt-admin@ietf.org
- Thread-Index: AcINdhBXmFBvz8gaT2yldS30ky6YvwA7EhFA
- Thread-Topic: Answers about draft-ietf-avt-rtp-selret-04.txt
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
> importance levels,
> for example: MPEG4.
[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]
> 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.
[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.
> > *what is the bandwidth saving of selective request vs requesting
> > every packet in the RTCP session?
[Jose]
> 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.
[David]
Refer to the above comment.
> > *what is the bandwidth added overhead of using the selective
> > retransmission in the RTP session?
[Jose]
>
> 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.
[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
> > *what is the penalty of requesting only some of the lost packets
> > 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.
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt