Subject: RE: [AVT] Retransmission draft

From: "[email-masked]" <[email-masked]>
Date: Thu, 4 Dec 2003 12:49:31 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Jose Rey" <[email-masked]>
Date: Mon, 8 Dec 2003 11:35:02 +0100

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: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Thursday, December 04, 2003 6:50 PM
> To: [email-masked]
> Subject: RE: [AVT] Retransmission draft
>
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 8 Dec 2003 10:46:01 +0000

Jose,

--> "Jose Rey" <[email-masked]> writes:
> 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.

Note that there's nothing in RFC 2733 that requires FEC to be sent with a
fixed repetition scheme. One could imagine a scenario where the receiver
used the RTCP feedback extensions to inform the sender of loss, and the
sender then generated FEC packets on demand to correct that loss...

Colin