IETF 70 - Vancouver

FECFrame WG meeting minutes

Marshall - Summarized the design protocol team's work.

Magnus - Pointed out an error on the slide that SDP is not a protocol

Mark - Presented the update on -01 version of framework.

Greg - Asked the AD about freezing the draft?

Magnus - Clarified that he could resurrect the draft !!!

Magnus - Requested to compress the ASCII diagram

Dave -

Mark - Should it be WGLC independent of SDP draft?

Marshal - Has been done before. Ask the group!

Magnus - Perhaps, worth waiting due to ISEG processes.

      Move the req and framework docs together.

Marshal - let's move both of them together forward for LC

Rajiv - I agree.

Magnus - Systematic vs non-systematic!!

Marshall - Clarified the fairness due to congestion.

Magnus - Network feedback should be utilized

Lorenzo - Congestion control is not quite problem in this context.

              backward compatible??

Mark - Yes. Compatible.

Rajiv - No strong opinion. Let's not hardcode the framework to

systematic code. While the preference is for the systematic code,

Mark - We should also include some verbiage

Ali -

Magnus - Different FEC codes may be selected due to different bitrates

and IPR issues. Let's not lock-in to just systematic code.

Mark - IPR has not been discussed yet. May already exist.

Ali - Makes more sense to prefer systematic code.

Greg - No technical reason to not include non-systematic code.

Ali - presents his SDP draft.

Dave - Something subtle here, both sender and receiver must get the

necessary CDP information in order to configure themselves. How it gets

conveyed is independent. A 3rd party could provide this info to sender

and receiver.

Mark - I agree. This comment has small impact to the framework. No

longer a blackbox. Needs to update the framework doc.

Rajiv - Wrt to previous comment, the CDP should take care of this (as

well).

Greg - How is this priority decided?

Mark - Draft doesn't seem to address how is this decided. Perhaps, by

the FEC scheme or CDP. The purpose of this draft -

Dave - Discuss this with MMUSIC whether there is an existing syntax for

priority/use of layering, and whether we can piggyback?

Magnus - ?

Ali - Layers don't depend on each other.

Magnus - reusing

Marshal - Let's relook into this again.

Magnus - It is still an I-D.

Greg - I-D name??

Dave - Is this scheme-id encoded within the packet?

Mark - Yes.

Dave - It is good.

Magnus - Just

Mark - Just need an IANA registry for the FEC scheme id. Identifying the

FEC scheme id in the SDP.

Magnus - Give some guidance on the space of FEC scheme id !!

Marshal - Misuse of the space is possible.

Dave - Is min-buff-size related to the source block size?

Ali - Yes.

Dave - Is there a level of abstraction problem here?

Magnus -

 Mark - In some sense, this may not only be receiver, but also source

related.

Mark - The milisec as a unit is not appropriate. Perhaps, # of blocks!!

Gerg - Is this what you referring to as well, Dave?

Dave - Time and Space relationship!! What's the right unit to express

receiver requirement!! Transmitter can utilize calculate accordingly. No

need for transmitter and/receiver to be configured separately.

      Both transmitter and receiver must utilize the same value.

Mark - that's right. Buff-size is not appropriate name. Also need to

change the unit to block size etc.

      As far as FEC is converned, the first block and last block.

Dave - I don't follow. Let's assume total source block+FEC = m+k packet.

Why couldn't I send m+k-1 packets now, and send the last packet 10 days

later. Not optimal to specify the "time" as a unit for the

min-buff-size. It will create an issue.

Mark - I agree. This is application specific. Shouldn't be mandatory.

Application may not need to wait for all the repair packets for its

functionality.

Marshall- could ms be too long for high data rate stream??

Dave - Good point.

Magnus - A smaller unit than ms should be advised.

Magnus - Expand the usage of rfc

Ali - Explains Mcast consideration and unicast consideration.

Dave - My comment is not about this doc. What we really like to have is

a metric reporting as part of that framework. In terms of how successful

receivers are able to utilize the FEC scheme for recovery.

      Perhaps, receiver uses RTCP to report back the efficacy

      of each FEC scheme.

      The WG should undertake this work.

Magnus - Makes sense.

Magnus - For unicast, Offer/answer model can get complicated. Should CDP

cover this requirement to simplify?

Mark - This is a good commnt on the fecframe requirment doc.

Mark - About measurement/metric reporting, how much do we need to

include this?

Marshall - A speculation for # of packets is possible.

Mark -

Magnus - Operations !

Marshall - Do we need a MIB?

Magnus - No. How do we configure and measure performance of a particular

scheme? This needs to be included in the framework.

Greg - Chair to AD Q - Where does this fit in? framework doc?

Requirement doc?

Magnus - It belongs to the framework doc.

Mark - May be. It depends on how far you wanna go. It is upto CDP what

needs to be measured. Or we can advise this to be independent of CDP or

FEC scheme. Measurement is an add-on.

Greg - it hsould be in the doc.

Mark - What measurements do we need to take when FEC doesn't exist. This

will help to quantify whether FEC really helps or not.

Rajiv - Agreed.

Vincent - Sent few comments to this draft. One Q - Is session consiered

to be dynamically change? Does the draft include provision for

accommodating this dynamism?

Magnus - You are right. SDP is not the right choice for such dynamism.

SDP is suitable for the stable flow i.e. flows not changing dynamically.

Mark - Just to add - We are not requiring CDP to use SDP. If an

application wants to add/remove flows, then it is a bigger problem, not

job of SDP.  Perhaps, job of CDP.

People can use other than SDP.

Magnus - it is ok to leave UDP as the transport protocol in the draft.

Greg - Should we adapt this as the WG doc?

Magnus - Yes.