[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Answers about draft-ietf-avt-rtp-selret-04.txt
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: "David.Leon@nokia.com" <David.Leon@nokia.com>
> > To: "bfoster@cisco.com" <bfoster@cisco.com>,
> > "Viktor.Varsa@nokia.com" <Viktor.Varsa@nokia.com>
> > Cc: "naoshad@cisco.com" <naoshad@cisco.com>, "avt@ietf.org"
> > <avt@ietf.org>,
> > "burmeister@panasonic.de" <burmeister@panasonic.de>
> > 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:bfoster@cisco.com]
> > > Sent: Thursday, April 25, 2002 4:12 PM
> > > To: Leon David (NRC/Dallas); Varsa Viktor (NRC/Dallas)
> > > Cc: Naoshad Mehta; avt@ietf.org; burmeister@panasonic.de
> > > 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
> > avt@ietf.org
> > https://www1.ietf.org/mailman/listinfo/avt
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www1.ietf.org/mailman/listinfo/avt
> >
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt