Subject: [Fecframe] Minutes

From: "Greg Shepherd" <[email-masked]>
Date: Wed, 4 Apr 2007 08:45:21 -0700

*,

Here are the minutes from Prague. Please review them for sanity before I
post them later this week.

Mark presenting FECframe document update:
  - requirement status is frozen, no comments since ietf67
  - open issues:

    - Fec scheme requirements

      - Most requirements can be likely imported from RMT

      - Lorenzo: feedback from RMT: good to have this scheme definition
        to have good quality of resulting FEC drafts later on

    - Q: are there any transport specific considerations
      - considered: UDP and DCCP
      - Rajiv Asati: L4 ? Yes.
      - Q: has RTP been cnsidered ? Currently arbitrary flow across
        UDP - includes of course RTP (on top of RTP). A: nothing specific
    to RTP currently. RTP is on top of UDP. Other groups (DVB) have
    tried to do this. Pro and Cons of trying to be specific to RTP.
      - James Wendel/Microsoft: RTP is also a framework in itself.
        there are fields in RTP obvious you wold want to exploit. RTP
    is for time critical flows. Some impact on semantics too.
      - Greg/Mark: Specific FEC scheme could rely on existing RTP fields
        and not need to add them to it's own header. ALso backward
compatible
      - Lorenzo: Hybrid scheme possible ? (Header format that is flexible
        to be optimized with RTP as payload vs. non RTP payload).
    Mark: Mostly documentation issue.
      - CMagnus: (didn't understand what he said)
      - Lorenzo: Add permanent piece of header and optional header
        only present when payload is not RTP.
      - Magnus: probably not useful from complexity perspective.

    - sdp elements...
      description of properties of toolkit of SDP elements to be used
      in content delivery protocols. Not normative, but indicidual FEC
      schemes may choose to use them.
        - transport protocol identifiers for FEC repair flows
        - Association of source flows to repair flow
        - FEC-scheme specific configuration
      - Greg: Rosetta stone draft needed describing where information is
        being pulled in from (RMT specs, etc..)
      - Rajiv: Why SDP ? Mark: Not manadated, optional.
      - SPD requires coordination with mmusic, avt and rmt.

 Next Steps:
   - Streaming Content Delivery Protocol. Need to defne a specific protocol,
     maybe based on SDP toolkit, provide explicit example cases. Have
     an example of a concrete example of how to use the framework.
     - Greg/Mark: separate document from Framework.
     - (Unnamed) Proposal: Just use XOR as a simple example

 - Lorenzo: What plans to take from what RMT did ?
  - Mark: Could be lot of reuse of RMT work. Maybe just a few pages spec
    in FEC frame and refer to an algorithm defined in RMT.
  - Mark: Do we want to systematically pull in RMT ? Probably not,
    leave it up to proponents of individual schemes.
 - Lorenzo: IANA registration defined ?
  - Mark: not yet. Probably in future. Three choices:
    - Dfine when signaling of FEC is defined
    - Do same thing as RMT did (signaling independent code space)
    - Directly clone/reuse RMT defined code space.
  - Rajiv: Preferred solution to reuse work from RMT
  - Magnus: Only 256 code points in RMT definition. Maybe too little.
    Especially with dynamic mapping.

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

---

From: "Greg Shepherd" <[email-masked]>
Date: Wed, 11 Apr 2007 08:41:56 -0700

Again?

Greg

---------- Forwarded message ----------
From: Greg Shepherd <[email-masked]>
Date: Apr 4, 2007 8:45 AM
Subject: Minutes
To: [email-masked]

*,

    - sdp elements...

 Next Steps:

Thanks,
Greg