 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Hi, > Hi, > > As I stated previously, I do not
fully understand the motivation for using a > separate flow for conveying FEC
payload mapping information. As stated in your draft: “Add padding (bytes containing binary zeroes) so that the byte array is in the size of the largest packet protected by this source block including the two bytes from section a. (The largest packet does not contain zero padding).”, conveying FEC payload mapping information in repair flow needs padding. But padding may lead to recovery performance degradation. We give an example, as the figures show below. For the padding case as depicted in Figure 1, the redundant data for recovering the packet of length 11 is 48, which is same as that for the packet of length 40.Figure1.
Source block with padding |-Source Block---| +----------------+|40xxxxxxxxxxxxxx|+----------------+|xxxxxxxxxxxxxxxx|+----------------+|xxxxxxxxxx000000|+----------------+|11xxxxxxxxxxx000|+----------------+|0000000000000000|+----------------+|0000000000000000|+----------------+For a non-padding case as depicted in Figure2, recovering the packet of length 11 only requires redundant data of length 16. The redundancy is much less than the padding case. Figure 2. Source block without padding|-Source Block---| +----------------+|40xxxxxxxxxxxxxx|+----------------+|xxxxxxxxxxxxxxxx|+----------------+|xxxxxxxxxx000000|+----------------+|11xxxxxxxxxxx000|+----------------+
If choosing
non-padding strategy as an alternative for FEC protection, the position of
source packet cannot be acquired simply by the sequence number. The information
with greater detail, for example ESI of each source packet, have to be conveyed.
These information may expand the FEC header in the repair flow to a fairly
large size. An alternative is to convey them in a separate flow. > A generic mapping scheme for
building source blocks of the variety of practical > FEC codes is a good idea, however I
believe that this should be indicated in the > designated repair flow. > > Until it is so, I don't believe
that we should adopt > draft-zixuan-fecframe-source-mi as
a working group item. > The focus of our
draft is on backward-compatibility issue. Separate flow is just an option. Based
on the previous discussion on the draft, now we think defining a generic mapping
information format for various ways of building source block in practice should
be the most important issue for backward compatibility. We suggest to make this
work (defining a generic mapping information format) to be a work item. We can
update our draft to be the basis of this work. -----Original Message----- > From: Einat
Yellin (Lachover) [mailto:Einat at radvision.com] > Sent:
Tuesday, October 06, 2009 11:00 PM > To:
gjshep at gmail.com > Cc:
zouzixuan; Ali C. Begen (abegen); tme at multicasttech.com; > fecframe at ietf.org > Subject:
RE: Working Group Item? was: Re: > [Fecframe]draft-zixuan-fecframe-source-mi
?? > > Hi, > > As I stated previously, I do not
fully understand the motivation for using a > separate flow for conveying FEC
payload mapping information. > > A generic mapping scheme for
building source blocks of the variety of practical > FEC codes is a good idea, however I
believe that this should be indicated in the > designated repair flow. > > Until it is so, I don't believe
that we should adopt > draft-zixuan-fecframe-source-mi as
a working group item. > > Best regards, > Einat > > -----Original Message----- From: fecframe-bounces at ietf.org
[mailto:fecframe-bounces at ietf.org] On Behalf Of zouzixuan Sent: Monday, September 28, 2009 10:57
AM To: 'Ali C. Begen (abegen)'; Einat
Yellin (Lachover); tme at multicasttech.com; gjshep at gmail.com; fecframe at ietf.org Subject: Re: [Fecframe]
draft-zixuan-fecframe-source-mi ?? Hi, Ali > I am not questioning backward
compatibility, I am questioning the cost for it > and the scenarios where we want
backward compatibility. Einat did a good > summary, so now the WG needs to
provide input. You mean there should be some input on
backward compatibility to the framework. > Regarding your example, putting the
audio and video packets into the source > blocks as they are available does
not seem to be a good design choice to me. > When I say "systematic,"
I mean you can create your source blocks in a > deterministic way (such as 4
packets from stream 1, one packet from stream 2). > Variable-packet size can be
handled. In this "systematic" case, how
could we know the position of a packet in the source block? [Einat] There are different ways to
signal the source block structure. In our draft we followed rfc 5109 and
used the 'base' (first) RTP sequence number along with a bitmap. This works for
the cases where what matters is which RTP packets belong to this FEC source
block and the order of the packets in the FEC source block is deterministic
(from lower SN to higher SN and from lower flow ID to higher flow ID). If a
more detailed structure of source block is needed then I agree that the bitmap
is not enough. Still, this information can be sent as part of the repair packet
header which IMO makes more sense. |