RE: [AVT] Retransmission draft

Hi Vinay,

thanks for your feedback. Let me try to clarify: the statement says there
are other alternatives to solve the problems the retransmission addresses.
However, this doesn't mean that these other solutions are better or worse.
It is a matter of trade-off between, e.g., client/server complexity, buffer
space and bit rate available.  And these depend on your scenario (!).
Typically, FEC and packet interleaving schemes offer less protection for the
same available bitrate, as pro-active schemes send redundant packets in
advance. You also need to XOR-encode and -decode packets.  FEC and packet
interleaving have a fixed repetition scheme, which means that packets are
repeated a fixed number of times (whether they are lost or not!) whereas
retransmission is more flexible here by allowing each lost packet to be
retransmitted as often as necessary within the given timing constraints.  An
advantage of pro-active schemes might be that they don't require a feedback
channel. On the other hand, retransmission of packets will use just the
bandwidth necessary to re-send lost packets.  You can also incorporate
packet scheduling into your retransmission server, which may enhance the
quality at the client.  In summary, you shall carefully address your needs
and evaluate which solution delivers the best compromise. You may want to
read RFC2354 which describes how to approach such a decision.

Hope this helps,

José

> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of
> vsathe@san.rr.com
> Sent: Thursday, December 04, 2003 6:50 PM
> To: avt@ietf.org
> Subject: RE: [AVT] Retransmission draft
>
>
> With this disclaimer, I am now confused about the prespective
> with which I
> should read this draft as a (potential) implementator. I
> understand that
> Matsushita may have some IPR in this submission. But now are
> you saying
> that you really don't know why anyone should use this scheme?
> Would it be
> possible to give a scenario or two where the proposed mechanism may be
> superior to follow? What is the point in sending this off to IETF RFC
> track?
>
> Thanks in advance for your explanation.
>
> Vinay Sathe
> Multirate Systems
>
> right, how about this:
>
> "This document provides an RTP packet retransmission
> mechanism for repair of
> streaming media.  The purpose of this paragraph is to make
> the reader aware
> that the retransmission mechanism described in this document may be
> encumbered by patent applications filed from Matsushita.  For
> details on the
> IPR statement, please visit the IETF IPR web page
> http://www.ietf.org/ietf/IPR.
>
> However, packet retransmission is not the only means for
> streaming clients
> and servers to cope with packet losses.  A detailed
> description of options
> for repair of streaming media is given in RFC2354.
> Therefore, implementers
> of this protocol shall take into account that there are in fact other
> mechanisms, such as forward error correction (FEC) or packet
> interleaving
> that represent an alternative to solve the problems packet
> retransmission
> tries to solve.    In particular RFC2733 and RFC2198 present FEC and
> redundant packet transmission schemes that might well fit to
> the needs of
> the implementer. "
>
> José
>
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>
>
> _______________________________________________
> 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