Subject: [MMUSIC] Comments on draft-li-mmusic-fec-grouping-00

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jul 2005 11:38:15 +0200

Hi Adam,

Here is the comments on the FEC grouping mechanism. I think it looks 
quite good, but there are a few things needing to be fixed in my view.

First a general comment. This should be well specified as not being 
specific to ULP. We already has another potential user of this grouping 
attribute in draft-watson-tsvwg-fec-sf-00.txt.

1. Section 3, first paragraph:
compare to other error correction technique (such
    as re-transmission), FEC can achieve much lower transmission delay,
    and does not have the problem of implosion.

What type of implosion are you referring to here?

2. Section 3, third paragraph:
    When FEC data are multiplexed with the original payload stream, the
    association relationship is indicated as specified in RTP Payload for
    Redundant Audio Data (RFC 2198) [4].

To make things a bit more clear and not restricted to a only ULP I think 
you need to include ULP as an informational reference and saying it may 
be done in that way as ULP do.

3. Section 4th paragraph:

  When FEC data are sent as a separate stream from the payload data,
    the association relationship SHOULD be indicated with the FEC media
    line grouping as specified in this document.

I have some problem with the SHOULD. This mechanism is intended to be 
used to indicate the relation ship. However it is not this 
specifications role to force that usage. Rather I think it is the actual 
usage specifications that should indicate this usage. Thus I think a 
reformulation is in order.

4. Section 5: first paragraph:

"There is a weak threat for the receiver that the FEC grouping can be
    modified to indicate FEC relationships that do not exist."

What would that result in then? I think some better motivation why this 
is dangerous or if it is only resulting in failure of FEC support.

5. Is the FEC grouping attribute allowed to be used over layered and/or 
multiple media declarations. I think one should allow it but it is 
probably best to define it in such way that this is evident.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Adam Li" <[email-masked]>
Date: Wed, 27 Jul 2005 09:35:54 -0700

Hi Magnus,

Thank you very much for the comments. Some replies inline below. I will
update the draft to address the comments soon. 

Adam

> attribute in draft-watson-tsvwg-fec-sf-00.txt.

Sure. I will keep the draft as generic and only use ULP as an example
application.

> What type of implosion are you referring to here?

This refers to the implosion when re-transmission is used with
broad/multi-casting. I will clarify in the next version of the draft.

> be done in that way as ULP do.

Will do that in the next version of the draft.

> reformulation is in order.

I agree with you. Other mechanisms can be used as well. The line grouping is
one of ways to indicate the relationship. I will correct it in the next
version.

> is dangerous or if it is only resulting in failure of FEC support.

It could potentially increase the workload of the receiver. Some consistency
check should be able to pick out the falsely indicated relationship. I will
clarify that in the next version.

> probably best to define it in such way that this is evident.

Magnus, I am not sure I understand this one. Could you clarify it?

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Jul 2005 10:38:47 +0200

> Magnus, I am not sure I understand this one. Could you clarify it?

What I mean is that for FEC codes that allow scalability layering using 
either different ports or even different addess. Thus potentially 
needing multiple m= lines to indicate the different layers.

I also think of draft-watson-tsvwg-fec-sf-00 where you will have a 
number of source streams (m= lines) that results in a single repair 
stream. These must be correctly grouped together. Thus you will have 
multiple m= blocks.

I don't see any problem using the FEC grouping attribute for either, 
however I think it is best to be explicit that it is possible to use the 
grouping in such a way.

Cheers

Magnus Westerlund