Re: [Fecframe] FECFrame WG Minutes IETF 75

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

> -----Original Message-----
> From: Watson, Mark [mailto:[e-mail]]
> Sent: Tuesday, September 01, 2009 12:53 AM
> To: Ali C. Begen (abegen); Ye-Kui Wang
> Cc: [e-mail]
> Subject: Re: [Fecframe] FECFrame WG Minutes IETF 75
> 
> Ali,
> 
> When you say “If a scheme only cares about SDP, ... ” you are voting for option (1) !

:) I understand your point below and agree with it. I rather meant to say an fec scheme could define the ascii fssi only first if its primary usage was with SDP. Later, a binary protocol could carry it through appropriate encapsulation. This is option 2, and I have a slightly more preference for this one.

 
> Again, the point (well, one point) of the Framework was to decouple FEC Schemes from the
> content delivery protocols that use them: so the design of an FEC Scheme should be
> independent of the content delivery protocols and vice-versa.
> 
> With options (2)/(3), we have to choose, in the Framework, whether to require all schemes
> to define encodings in binary, ACSII or both for the scheme-specific information and all
> schemes MUST define the encodings that the Framework requires. This is the only way that
> future content delivery protocol designers could be sure that all schemes will work with
> their protocol.

Agree. And I vote for (2).

 
> Btw, what do you propose for the ASCII encoding rules that FEC Schemes must follow ? For
> example, what will be the delimeter in SDP, how should be be escaped, what is the allowed
> character set ?

While it does not answer all these questions, I have an example in the sdp draft:
http://tools.ietf.org/html/draft-ietf-fecframe-sdp-elements-04

-acbegen
 
> ...Mark
> 
> 
> On 8/31/09 2:18 PM, "Ali C. Begen (abegen)" <[e-mail]> wrote:
> 
> 
> 
> 	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
> 
>