Subject: [Fecframe] Draft Minutes

From: "Greg Shepherd" <[email-masked]>
Date: Sun, 30 Dec 2007 02:55:24 -0800

Please read and send me any comments/corrections

Thanks,
Greg

--------

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.

_______________________________________________
Fecframe mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/fecframe