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

["Rajiv Asati (rajiva)" <[e-mail]>]

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

I agree with Mark. We should just say that the existing means (RFC4756)
just don't solve the FEC framework requirements. Such text conveys the
lack of solution a lot better.  

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

Good catch. Must be incorporated in the next version of the draft.

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

The more I think about it, the more I realize that we should not mandate
a particular transport layer or protocol for the repair flow, though the
preferred option may be highlighted. We should _not_ deny RTP to be the
transport protocol for the repair flow, independent of what's used for
source flow. This opens up the framework to benefit from the avantages
such as the usage of RTCP for reports, the sequencing etc. Moreover, the
underlying IP network can also benefit from the RTP usage (to employ
flow monitoring using seq#, for example). 

Also, the FEC framework architecture building block diagram needs to be
updated to show that FEC framework block can get the media payload
directly from the application (MPEGoUDPoIP, for example). Overall, the
architecture building block should be updated as shown in the attached
slide.

 <<Microsoft PowerPoint Slide>> 

Cheers,
Rajiv

> -----Original Message-----
> From: Mark Watson [mailto:[e-mail]] 
> Sent: Monday, February 18, 2008 9:24 PM
> To: Ali Begen (abegen); Rajiv Asati (rajiva); [e-mail]
> Subject: Re: [FECFRAME-PROTO] A new informational draft on 
> fec grouping issues
> 
> 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]
https://www.ietf.org/mailman/listinfo/fecframe-proto