Subject: [FECFRAME-PROTO] A new informational draft on fec grouping issues

From: "Ali Begen (abegen)" <[email-masked]>
Date: Tue, 12 Feb 2008 13:03:46 -0800

Hi everyone,

So far, we could not ignite a discussion in the MMUSIC WG regarding the
FEC grouping issues. So, it was suggested that I would write an
informational draft, describe the problems and propose some alternative
solutions. So, that is what I did.

I am attaching the draft for your review. Note that this has to be
submitted by Monday. So any comments within this week (before Friday)
would be appreciated. It is important that we convey our issues
appropriately. So, please take a few minutes to review the document. It
is very short, and should not take much time.

Thanks,
-acbegen
_______________________________________________
FECFRAME-PROTO mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/fecframe-proto

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 12 Feb 2008 16:16:36 -0500

Hi Ali,

We (the protocol team) should all collaborate to jointly author the new
draft, if/when it needs to be produced.

Also, why should it be the informational draft? 

Cheers,
Rajiv 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ali 
> Begen (abegen)
> Sent: Tuesday, February 12, 2008 4:04 PM
> To: [email-masked]
> Subject: [FECFRAME-PROTO] A new informational draft on fec 
> grouping issues
> 
> Hi everyone,
>

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Tue, 12 Feb 2008 13:28:16 -0800

This is just for describing the problem and showing some alternative
solutions. It does not have to become anything. That's why, it is
intended to be informational.

If MMUSIC agrees to adopt one of the solutions described here or comes
up with a new one, then of course we should work on that draft together,
which should be in the cateogry of "proposed standard."

However, note that MMUSIC WG should approve what needs to be done here.
And, that's why we need to tell them about our problems.

-acbegen 

> From: Rajiv Asati (rajiva) 
> Sent: Tuesday, February 12, 2008 1:17 PM
> To: Ali Begen (abegen); [email-masked]
> Subject: RE: [FECFRAME-PROTO] A new informational draft on 
> fec grouping issues
> 
> Hi Ali,
> 
> We (the protocol team) should all collaborate to jointly 
> author the new draft, if/when it needs to be produced.
> 
> > [mailto:[email-masked]] On Behalf Of Ali Begen 
> > (abegen)
> > Subject: [FECFRAME-PROTO] A new informational draft on fec grouping 
> > issues
> > 
> > Hi everyone,
> > 
> > So far, we could not ignite a discussion in the MMUSIC WG regarding 
> > the FEC grouping issues. So, it was suggested that I would write an 
> > informational draft, describe the problems and propose some 
> > alternative solutions. So, that is what I did.
> > 
> > appropriately. So, please take a few minutes to review the 
> document. 
> > It is very short, and should not take much time.
> > 
> > Thanks,
> > -acbegen
> > 
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 13 Feb 2008 08:36:10 -0500

Hi Ali,

That's fine. 
I just got to see the draft. Looks fine to me.

Cheers,
Rajiv

> From: Ali Begen (abegen) 
> Sent: Tuesday, February 12, 2008 4:28 PM
> To: Rajiv Asati (rajiva); [email-masked]'
> This is just for describing the problem and showing some 
> alternative solutions. It does not have to become anything. 
> That's why, it is intended to be informational.
> 
> If MMUSIC agrees to adopt one of the solutions described here 
> or comes up with a new one, then of course we should work on 
> that draft together, which should be in the cateogry of 
> "proposed standard."
> 
> However, note that MMUSIC WG should approve what needs to be 
> done here. And, that's why we need to tell them about our problems.
> 
> -acbegen 
>

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Wed, 13 Feb 2008 07:45:20 -0800

Hi Rajiv,

Thanks for reading the draft. For other who have not started reading,
pls see the updated version (attached).

I asked someone without any FEC background to comment on the draft
(seems that we will have the same issue in MMUSIC). So, I expanded the
intro part and make clarifications about what we meant with
prioritization, additivity, etc.

Thanks again,
-acbegen

> Sent: Wednesday, February 13, 2008 5:36 AM
> To: Ali Begen (abegen); [email-masked]'
> > Subject: RE: [FECFRAME-PROTO] A new informational draft on fec 
> > grouping issues
> > 
> alternative 
> > solutions. It does not have to become anything.
> > up with a new one, then of course we should work on that draft 
> > together, which should be in the cateogry of "proposed standard."
> > 
> > However, note that MMUSIC WG should approve what needs to be done 
> > here. And, that's why we need to tell them about our problems.
> > 
> > -acbegen
> > 
> > > Subject: RE: [FECFRAME-PROTO] A new informational draft on fec 
> > > grouping issues
> > > 
> > > Hi Ali,
> > > 
> author the 
> > > new draft, if/when it needs to be produced.
> > >

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 13 Feb 2008 11:08:04 -0500

Hi Ali,

Two quick comments -

Perhaps, we should move the text related to requirements in a separate
section from the Introduction section for better readability.

Also, 3.2 and 3.3 are new, hence, they are not really "issues" or
limitations with existing mechanisms. Perhaps, we could move them into
"Requirements" section for completeness and clarify there. 

Cheers,
Rajiv

> Sent: Wednesday, February 13, 2008 10:45 AM
> Thanks for reading the draft. For other who have not started 
> reading, pls see the updated version (attached).
> 
> I asked someone without any FEC background to comment on the 
> draft (seems that we will have the same issue in MMUSIC). So, 
> I expanded the intro part and make clarifications about what 
> we meant with prioritization, additivity, etc.
> 
> Thanks again,
> -acbegen
>

---

From: Mark Watson <[email-masked]>
Date: Fri, 15 Feb 2008 18:23:08 -0800

Ali,

Sorry if these comments are a little late. They are non-essential apart from
(7).

1) At the end of Section 3.1, you say the group attribute specification
'mandates us to write a=group:FEC S1 S2 R1 R1'. Actually, I think it would
be more accurate to just say that the grouping specification does not
support the case described at all.

Writing 'a=group:FEC S1 S2 R1 R1' clearly doesn't make any sense in this
case: it would be a defect in the specification if it 'mandated' something
which made no sense, whereas I think a better way to look at it is that the
specification simply doesn't address this case.

2) I'm not sure what is meant by the next sentence 'Note that source and
repair flows are identified by their payload formats and/or other
descriptors [I-D.begen-fecframe-sdp-elements].' Also, it doesn't seem
relevant in this context where we describe limitations of the other
specifications.

3) 3.3. - the requirement to obey the prioritisation is a SHOULD in this
context, since it is just an optimisation.

4) 3.3 - 'It might be highly desirable to keep all the receivers ...' -
'all' should be 'most'.

5) 3.3 - 'Currently, there is no SDP semantics for indicating the priority
levels of the individual flows that are grouped in an "a=group" line.' -
remove from 'that are grouped ...' onwards, since we have not decided to use
the a=group and indeed are pointing out where it is deficient

6) 4 - 'There are two main solution approaches.' - That's a broad statement!
Perhaps you mean there are two solution approaches described in the draft ?
Another possibility would be to define an fec-specific mechanism, where each
repair flow simply refers directly to the protected source flows (this is
done in 3GPP, for example).

7) 4.1 and 4.2 - in the examples, the FEC repair flows should be
'application' not 'video' type and the transport identifier should be
'udp/fec', not 'rtp/avp'. There should not be an rtpmap attribute.

...Mark

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Fri, 15 Feb 2008 20:23:22 -0800

Hi Mark,

Thanks for the review. I submitted it yesterday, but I will make the
changes in the next submission (or mention them in the meeting, if we
can get a slot).

My comments are in between. 

> Ali,
> 
> Sorry if these comments are a little late. They are 
> non-essential apart from (7).
> 
> 1) At the end of Section 3.1, you say the group attribute 
> specification 'mandates us to write a=group:FEC S1 S2 R1 R1'. 
> Actually, I think it would be more accurate to just say that 
> the grouping specification does not support the case described at all.
> 
> case: it would be a defect in the specification if it 
> 'mandated' something which made no sense, whereas I think a 
> better way to look at it is that the specification simply 
> doesn't address this case.

In the context of RFC 4756, the way I understand it is permissible to
write "a=group:FEC S1 S2 R1 R2." It would not make much sense, I agree,
but it is not forbidden, either.  This line is also a valid statement
from 3388's perspective. Is not it?

> 2) I'm not sure what is meant by the next sentence 'Note that 
> source and repair flows are identified by their payload 
> formats and/or other descriptors 
> [I-D.begen-fecframe-sdp-elements].' Also, it doesn't seem 
> relevant in this context where we describe limitations of the 
> other specifications.

I'll clarify here.
 
> 3) 3.3. - the requirement to obey the prioritisation is a 
> SHOULD in this context, since it is just an optimisation.

If I recall correctly from the design team meeting, we set this to a
MUST. If you think it should be a SHOULD, we should discuss it. The
current SDP draft also says it is a MUST.
 
> 4) 3.3 - 'It might be highly desirable to keep all the 
> receivers ...' - 'all' should be 'most'.

OK.

> 5) 3.3 - 'Currently, there is no SDP semantics for indicating 
> the priority levels of the individual flows that are grouped 
> in an "a=group" line.' - remove from 'that are grouped ...' 
> onwards, since we have not decided to use the a=group and 
> indeed are pointing out where it is deficient

OK. 
 
> Perhaps you mean there are two solution approaches described 

Agree.

> Another possibility would be to define an fec-specific 
> mechanism, where each repair flow simply refers directly to 
> the protected source flows (this is done in 3GPP, for example).

So, we should simply say 'group s1 r1', 'group s1 r2', etc if all of
these repair flows are protecting s1? Is this what you meant? If that is
the case, we will need something additional to signal the additivity
since this approach does not differentiate the flows that are additive
from the ones that are not additive.

> 7) 4.1 and 4.2 - in the examples, the FEC repair flows should 
> be 'application' not 'video' type and the transport 
> identifier should be 'udp/fec', not 'rtp/avp'. There should 
> not be an rtpmap attribute.

You mean "m=video 30000 udp application" for the source flows and
"m=video 30000 UDP/FEC application" for the repair flows? Or, should the
media sub-fields be "application" as well?

BTW, is not using 'RTP/AVP' acceptable? At the end, we might be
protecting the whole RTP packets and the stream might actually carry
video, audio, etc? Or, we can't use examples with RTP/AVP for now since
no payload format is defined for using RTP with fec framework? 

(BTW, the examples are modified from the ones in SDP draft) 

Thanks,
-acbegen

---

From: Mark Watson <[email-masked]>
Date: Mon, 18 Feb 2008 18:24:20 -0800

Ali,

See comments inline...

> from 3388's perspective. Is not it?

To say something is "not forbidden" is different from saying it is
"mandated". The RFC simply doesn't give any indication of what to do in the
scenario we are talking about. You have read into it that because the only
thing close is a=group:FEC S1 S2 R1 R2 then this is that the RFC "intended"
for this case. But the RFC didn't intend anything for this case - you're
reading in more than it says. We might as well say the RFC mandates writing
"a=group:FEC" with just as much justification and making just as much sense
(i.e. None).

> from the ones that are not additive.

For example, we could have an fec-specific attribute (e.g. a=fec-repair) and
somewhere in that attribute line is the list of protected source flows.

> media sub-fields be "application" as well?

No, I mean "m=application 3000 udp/fec" for the repair flow. The repair flow
is not an audio or video flow.

The source flow syntax is unchanged by the use of FEC.

> 
> BTW, is not using 'RTP/AVP' acceptable?

No. The repair flows are not RTP flows. There is no RTP layer defined in the
repair packet format.

> At the end, we might be

If there is RTP involved, it's in the source flows, not the repair flow. So
it it not correct to say the repair flow is an RTP flow.

> (BTW, the examples are modified from the ones in SDP draft)

So, then, that is wrong as well. Any chance to update before the meeting ?