Re: [Fecframe] FECFrame WG Minutes IETF 75

[Ye-Kui Wang <[e-mail]>]

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
>