Subject: [Fecframe] FECFrame WG Minutes IETF 75

From: Greg Shepherd <[email-masked]>
Date: Wed, 26 Aug 2009 12:10:38 -0700

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

---

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 31 Aug 2009 11:42:46 -0400

One comment: The presenter of draft-zixuan-fecframe-source-mi-0 was Ye-Kui Wang (YK), not Zou ZiXuan (ZZ), who is the author of the draft. Therefore, it would be correct if you change "Zou ZiXuan (ZZ)" to "Ye-Kui Wang (YK)", and "ZZ" to "YK".

BR, YK 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Greg Shepherd
> Sent: Wednesday, August 26, 2009 3:11 PM
> To: [email-masked]
> Subject: [Fecframe] FECFrame WG Minutes IETF 75
> 
> corrections/feedback. They are available on the IETF WG 
> materials page but I've pasted them here for your reading pleasure.
> 
> Thanks,
> Greg
> 
> ----snip----
> 
> 	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.
> 
> Some minor clarifications, and updated contact info. Also 
> should be ready for last call after the meeting.
> 
> Marshall Eubanks (ME):
> 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):
> 	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.
> 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.
> 
> 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.
> 
> 	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: 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.
> 
> 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: 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.
> 
> 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.
> 
> ME: It would be a good design goal to allow different FEC 
> schemes to be dropped into this solution.
> 
> 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: 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.
> 	
> 	When you start trying to apply FEC across unrelated 
> sessions then you have really big problems defining what is 
> what and delineating things.
> Most of the complexity is in the RTP integration, independent 
> of any FEC.
> 
> AB: DVB was working on un-equal protection for media flows. 
> What happened to that? UpperLayer-FEC
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe
>

---

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 31 Aug 2009 11:58:58 -0400

> ZZ: For RTP receivers that my use FEC but do not support the 

What I said was something like "For RTP receivers not using FEC and not support the FECFramework, e.g. RFC 3984 recievers". 

> 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

---

From: "Watson, Mark" <[email-masked]>
Date: Mon, 31 Aug 2009 09:53:45 -0700

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" <[email-masked]> wrote:

> What I said was something like "For RTP receivers not using FEC and  
> not support the FECFramework, e.g. RFC 3984 recievers".
>
> 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
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 31 Aug 2009 14:18:33 -0700

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Watson,
> Mark
> Sent: Monday, August 31, 2009 7:54 PM
> To: Ye-Kui Wang
> Cc: [email-masked]
> Subject: Re: [Fecframe] FECFrame WG Minutes IETF 75
> 
> All,
>

---

From: "Watson, Mark" <[email-masked]>
Date: Mon, 31 Aug 2009 14:53:23 -0700

Ali,

When you say “If a scheme only cares about SDP, ... ” you are voting for option (1) !

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.

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 ?

...Mark

On 8/31/09 2:18 PM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 31 Aug 2009 15:14:40 -0700

> From: Watson, Mark [mailto:[email-masked]]
> Sent: Tuesday, September 01, 2009 12:53 AM
> To: Ali C. Begen (abegen); Ye-Kui Wang
> Cc: [email-masked]

:) 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
 
> 	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
>