Re: [Fecframe] FECFrame WG Minutes IETF 75

["Ali C. Begen (abegen)" <[e-mail]>]

I think 2/3 are the right approaches to take. If a scheme only cares about SDP, the choice is straightforward. If it cares about both SDP and binary protocols, it can adopt option 2 or 3. Between 2 and 3, I have a slight preference for 2.

-acbegen

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Watson,
> Mark
> Sent: Monday, August 31, 2009 7:54 PM
> To: Ye-Kui Wang
> Cc: [e-mail]
> Subject: Re: [Fecframe] FECFrame WG Minutes IETF 75
> 
> All,
> 
> Regarding the question of whether the scheme-specific information
> should be encoded in base64 or ASCII within SDP: the idea of the
> framework is to provide separation between fec schemes and the
> protocols that use them. So the fec scheme does not know whether the
> scheme-specific information will be carried in SDP or something else.
> A binary format was chosen so that if 'something else' is a binary
> protocol then the scheme-specific information can be efficiently
> carried.
> 
> So, then we have three options if we want to stick with the decision
> of the meeting:
> 1) abandon this idea of scheme/protocol independence and say that
> fecframe works only with SDP.
> 2) require schemes to define scheme-specific information in ASCII form
> and any binary protocols that are defined in future will need just to
> encapsulate those text strings, even of thils is a little inefficient
> 3) require schemes to define both text and binary versions of the
> scheme-specific inormation
> 
> Regards,
> 
> Mark
> 
> Sent from my iPhone
> 
> On Aug 31, 2009, at 8:59 AM, "Ye-Kui Wang" <[e-mail]> wrote:
> 
> >
> > A couple of more comments:
> >
> >> Zou ZiXuan (ZZ): draft-zixuan-fecframe-source-mi-0 –
> >> presenting for colleagues
> >>
> >> AB: Is it okay for the repair packet to have the FEC payload
> >> header – it must have something anyway – but you are adding
> >> this kind of header to the source packets?
> >>
> >> ZZ: No, FEC payload header is not added to the source packet,
> >> it’s added to the repair packet and the information mapping packet.
> >>
> >> AB: Do we really need to consider non-framework capable receivers?
> >>
> >> ME: I don’t believe this violates our charter. But why are
> >> you doing this work?
> >>
> >> ZZ: For RTP receivers that my use FEC but do not support the
> >> FECFramework.
> >>
> >
> > What I said was something like "For RTP receivers not using FEC and
> > not support the FECFramework, e.g. RFC 3984 recievers".
> >
> >> AB: We don’t modify the source packets anyway so this is not
> >> a problem.
> >>
> >> ZZ: The draft says it is recommended though optional to
> >> include this data.
> >>
> >> AB: All the cenarios we are aware of already use RTP and have
> >> sequence numbers so don’t need to include this data.
> >>
> >> ME: Chairs should prepair a letter to the list for use cases
> >> to see if we have responses.
> >>
> >> AB: This MIU would have to go into a separate datagram. What
> >> happens if it is lost or reordered. We need to be protected,
> >> robust at the receiver side.
> >>
> >
> > After the above comment I said that the draft does specify ways for
> > robustness, but anyway first of all we need to justify that the
> > problem is valid and needs a solution. I think it is valueable for
> > readers of the minutes to understand better the context if this
> > comment is added.
> >
> > BR, YK
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Greg Shepherd
> >> Sent: Wednesday, August 26, 2009 3:11 PM
> >> To: [e-mail]
> >> Subject: [Fecframe] FECFrame WG Minutes IETF 75
> >>
> >> Please take a look at the posted minutes and send me any
> >> corrections/feedback. They are available on the IETF WG
> >> materials page but I've pasted them here for your reading pleasure.
> >>
> >> Thanks,
> >> Greg
> >>
> >> ----snip----
> >>
> >> FECFrame WG Minutes, IETF 75, Stockholm, Sweden, July 27th
> >>
> >> Greg Shepherd (GS) – Agenda and status
> >> Framework draft should be ready for last call after the meeting
> >>      But we missed the cake ☹
> >>
> >> GS (for Mark Watson)
> >> Draft-ietf-fecframe-framework-05:
> >>      Many comments on the list. Most were clarification of
> >> terms. IANA considerations defined. No large changes to the
> >> framework per se, just mostly clarifications. Should be ready
> >> for last call after this meeting.
> >>
> >> Draft-ietf-fecframe-raptor-01:
> >> Some minor clarifications, and updated contact info. Also
> >> should be ready for last call after the meeting.
> >>
> >> Marshall Eubanks (ME):
> >>      Should we have the framework document go through the
> >> whole last-call process?
> >>
> >> GS: We had to rev it, due to so many comments on the list. So
> >> it will go through the last call process as it is now and
> >> will reflect any new comments agreed upon through the process.
> >>
> >> Ali Begen (AB):
> >>      Draft-ietf-fecframe-sdp-elements-03
> >>      Just a couple of issues in the previous version but
> >> were outside this draft, regarding grouping issues in SDP.
> >>      MMUSIC has updated RFC3388bis so it should be going for
> >> last call, and accordingly updated RFC4756bis. We now have
> >> what we needed for the grouping semantics.
> >>      I asked for last-call from MMUSIC for this draft.
> >> Waiting on people from this group to read and review. Please
> >> review so we can finalize RFC4756bis. It is a normative
> >> reference for the SDP-Elements draft.
> >>      Second issue of the SDP draft was the priority of repair flows.
> >> Previously we had a priority parameter in SDP to indicate
> >> decoding order of the repair flows set by the sender side.
> >> But “priority” word had several prior meanings. So now we’re
> >> going with preference level.
> >> It is optional. If you have multiple repair flows but you
> >> want your receivers to start decoding from a particular
> >> repair flow you can set the priority of decoding in SDP.
> >> Whether they follow the preference level is optional.
> >>      One issue that came up on the list was about a textual
> >> representation of the FEC scheme-specific information field.
> >> Some think it should be a human-readable ASCII field and
> >> others think it should be binary. We need to make a decision.
> >>
> >> ME: Are there any existing deployments?
> >> ME: I have a mild preference to ASCII.
> >> AB: I think you are an exception.
> >> GS: From memory the only issue which arose was around the
> >> deployment of a middle box that needed to decode the FEC
> >> Scheme-specific information field.
> >> AB: Still an open issue.
> >>
> >> Collin Perkins (CP): If it’s going into SDP in needs to be text.
> >>      SDP work in the IETF has always defined to be ASCII
> >> human-readable
> >>      If it’s something that has been defined in another
> >> standards body as a binary block then we ….mumble, mumble..
> >>      Show the counter example
> >>      Ultimately it doesn’t make much difference. ASCII may
> >> be easier to debug, binary may be more efficient – pick one
> >> and move on.
> >>
> >> AB: The whole information field is maybe 10 digits
> >>
> >> Room: Base64 – 1 hand
> >>      ASCII – 7 hands
> >>
> >> AB: We’re going to go with ASCII. This info will be included
> >> in the draft then I’ll ask to move to last call. Of course it
> >> will be waiting on the framework draft.
> >>
> >> GS: On process, can we forward them all at the same time
> >> though they are dependent. Magnus? Can they progress together?
> >>
> >> Magnus Westerlund (MW): Once you’ve established WG consensus,
> >> you can move them in parallel. Still need individual proto write-ups.
> >>
> >> Zou ZiXuan (ZZ): draft-zixuan-fecframe-source-mi-0 –
> >> presenting for colleagues
> >>
> >> AB: Is it okay for the repair packet to have the FEC payload
> >> header – it must have something anyway – but you are adding
> >> this kind of header to the source packets?
> >>
> >> ZZ: No, FEC payload header is not added to the source packet,
> >> it’s added to the repair packet and the information mapping packet.
> >>
> >> AB: Do we really need to consider non-framework capable receivers?
> >>
> >> ME: I don’t believe this violates our charter. But why are
> >> you doing this work?
> >>
> >> ZZ: For RTP receivers that my use FEC but do not support the
> >> FECFramework.
> >>
> >> AB: We don’t modify the source packets anyway so this is not
> >> a problem.
> >>
> >> ZZ: The draft says it is recommended though optional to
> >> include this data.
> >>
> >> AB: All the cenarios we are aware of already use RTP and have
> >> sequence numbers so don’t need to include this data.
> >>
> >> ME: Chairs should prepair a letter to the list for use cases
> >> to see if we have responses.
> >>
> >> AB: This MIU would have to go into a separate datagram. What
> >> happens if it is lost or reordered. We need to be protected,
> >> robust at the receiver side.
> >>
> >> Einat Yellin (EY): draft-galanos-fecframe-rtp-reedsolomon-mf-00
> >>
> >> Dave Oran (DO): There is an obvious goal for
> >> video-conferencing which is not in your goal list which is
> >> low source delay. Low recovery delay obviously, but long
> >> block will add more delay so are you going to show how this
> >> also provides low source delay?
> >>
> >> EY: Some background – trying to compensate for burst packet
> >> loss across multiple RTP flows.
> >>      The motivation is for video but there is nothing in the
> >> draft specifying the application for video only so any RTP
> >> payload would work.
> >>
> >> CP: Just trying to understand the use case. So you have an
> >> audio flow and a video flow and you want to generate one
> >> repair flow for the two or is it layered video flows? So all
> >> the flows are generated from the same host/user?
> >>
> >> EY: Different video flows which could be layered video or
> >> multiple video for a 3D video.
> >>
> >> CP: Just trying to see how they would map to RTP and it would
> >> be easier if they were in someway related rather than separate.
> >>
> >> Bill Versteig (BV): Is this fundamentally about how they map
> >> mutiple flows in the FEC or is there something Reedsolomon
> >> specific? A method to combine flows and map to FEC is
> >> interesting in the broad sense outside of just Reedsolomon
> >> specifically.
> >>
> >> EY: We don’t specify the specification of Reedsolomon.
> >>
> >> ME: It would be a good design goal to allow different FEC
> >> schemes to be dropped into this solution.
> >>
> >> EY: It would be more useful to have one draft to define in
> >> the generic sense.
> >>
> >> CP: You’re missing the case where you have multiple SSRCs in
> >> one RTP session
> >>
> >> BV: let’s fix these stream coralation problems in a non
> >> FEC-specific way so that we have a framework solution and we
> >> won’t have to do this for every FEC.
> >>
> >> CP: Try to think of more general use cases provided it
> >> doesn’t break this use case.
> >>
> >> ME: If this is going to be applied in a more generic case
> >> then we should have some sort of registry.
> >>
> >> CP: We have a registry – it’s the MIME-type registry.
> >>
> >> CP: You show repair window in microsecs? Perhaps RTP
> >> timestamp units instead, but complicated for multiple rows,
> >> that way it exactly maps onto the source flows.
> >>
> >> CP: Great open issues as applied to RTP
> >>      FEC across unrelated RTP (AVT) flows
> >>      Strongly encouraged to bring to the RTP WG
> >>      Great interest in solving these issues
> >>      When you start trying to apply FEC across unrelated
> >> sessions then you have really big problems defining what is
> >> what and delineating things.
> >> It’s not clear that this can be fixed within how RTP works.
> >>      This would fit better as an AVT draft to be reviewed by
> >> FECFrame.
> >> Most of the complexity is in the RTP integration, independent
> >> of any FEC.
> >>
> >> Vincent Roca (VR): draft-roca-fecframe-rs-01
> >>
> >> AB: DVB was working on un-equal protection for media flows.
> >> What happened to that? UpperLayer-FEC
> >>
> >> Jeff Goldberg (JG): It changed chairs but should still be active
> >>
> >> AB: 1&2 multiple source flows? (Yes)
> >>      We should work together for a common
> >>      Protection of multiple source flow doc is already a WG Item
> >>
> >> VR: LDPC-staircase
> >>
> >> VR: LDPC
> >>      WG Item? (to the list)
> >>
> >> AB: Pub request of interleave draft
> >>      1D/2D draft status?
> >>
> >> JG: LIason sent to DVB
> >>      DVB-AL FEC Draft
> >> SMTP ref 2022 / draft is incomplete
> >> DVB punting back to IETF $ SMPTE
> >>      Time to complete our work
> >>      No need to be contingent or wait on liason
> >>
> >> VR: General RPT payload format?
> >>
> >> CP: Definded by payload type
> >>      Multiple flow protection trick to go to AVT
> >> _______________________________________________
> >> Fecframe mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/fecframe
> >>
> >
> >
> > _______________________________________________
> > Fecframe mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/fecframe
> _______________________________________________
> Fecframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fecframe