Re: [Fecframe] FECFrame WG Minutes IETF 75
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fecframe] FECFrame WG Minutes IETF 75
> -----Original Message-----
> From: Watson, Mark [mailto:watson at qualcomm.com]
> Sent: Tuesday, September 01, 2009 12:53 AM
> To: Ali C. Begen (abegen); Ye-Kui Wang
> Cc: fecframe at ietf.org
> 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)" <abegen at cisco.com> 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: fecframe-bounces at ietf.org [mailto:fecframe-bounces at ietf.org] On Behalf Of
> Watson,
> > Mark
> > Sent: Monday, August 31, 2009 7:54 PM
> > To: Ye-Kui Wang
> > Cc: fecframe at ietf.org
> > 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" <yekuiwang at huawei.com> 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: fecframe-bounces at ietf.org
> > >> [mailto:fecframe-bounces at ietf.org] On Behalf Of Greg Shepherd
> > >> Sent: Wednesday, August 26, 2009 3:11 PM
> > >> To: fecframe at ietf.org
> > >> 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
> > >> Fecframe at ietf.org
> > >> https://www.ietf.org/mailman/listinfo/fecframe
> > >>
> > >
> > >
> > > _______________________________________________
> > > Fecframe mailing list
> > > Fecframe at ietf.org
> > > https://www.ietf.org/mailman/listinfo/fecframe
> > _______________________________________________
> > Fecframe mailing list
> > Fecframe at ietf.org
> > https://www.ietf.org/mailman/listinfo/fecframe
>
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
