Re: [Fecframe] FECFrame WG Minutes IETF 75

["Watson, Mark" <[e-mail]>]

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