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

[Mark Watson <[e-mail]>]

Ali,

See comments inline...


On 2/15/08 8:23 PM, "Ali Begen (abegen)" <[e-mail]> wrote:

> 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.
>> 
>> 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.
> 
> 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?
> 

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).


>> 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. 
>  
>> 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 ?
> 
> 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.

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.

> 
>> 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?

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
> 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?
> 

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 ?

> 
> Thanks,
> -acbegen
> 
>> ...Mark
>> 
>> 
>> On 2/13/08 7:45 AM, "Ali Begen (abegen)" <[e-mail]> wrote:
>> 
>>> 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
>>> 
>>>> -----Original Message-----
>>>> From: Rajiv Asati (rajiva)
>>>> Sent: Wednesday, February 13, 2008 5:36 AM
>>>> To: Ali Begen (abegen); '[e-mail]'
>>>> Subject: RE: [FECFRAME-PROTO] A new informational draft on fec
>>>> grouping issues
>>>> 
>>>> Hi Ali,
>>>> 
>>>> That's fine. 
>>>> I just got to see the draft. Looks fine to me.
>>>> 
>>>> Cheers,
>>>> Rajiv
>>>>  
>>>> 
>>>>> -----Original Message-----
>>>>> From: Ali Begen (abegen)
>>>>> Sent: Tuesday, February 12, 2008 4:28 PM
>>>>> To: Rajiv Asati (rajiva); '[e-mail]'
>>>>> Subject: RE: [FECFRAME-PROTO] A new informational draft on fec
>>>>> grouping issues
>>>>> 
>>>>> 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
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Rajiv Asati (rajiva)
>>>>>> Sent: Tuesday, February 12, 2008 1:17 PM
>>>>>> To: Ali Begen (abegen); [e-mail]
>>>>>> 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.
>>>>>> 
>>>>>> Also, why should it be the informational draft?
>>>>>> 
>>>>>> Cheers,
>>>>>> Rajiv
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: [e-mail]
>>>>>>> [mailto:[e-mail]] On Behalf Of Ali Begen
>>>>>>> (abegen)
>>>>>>> Sent: Tuesday, February 12, 2008 4:04 PM
>>>>>>> To: [e-mail]
>>>>>>> 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.
>>>>>>> 
>>>>>>> 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
>>> [e-mail]
>>> http://www.ietf.org/mailman/listinfo/fecframe-proto
>> 
>> 
>> 
> 


_______________________________________________
FECFRAME-PROTO mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/fecframe-proto