Subject: [Fecframe] Minutes from San Diego

From: Marshall Eubanks <[email-masked]>
Date: Wed, 6 Dec 2006 08:52:57 -0500

These Minutes have been posted for a while, but I have not seen them  
on the
list (which has been quiet since the meeting, so this is also a test  
of the list !).

If you have corrections, please send them by Friday.

Regards
Marshall
------
IETF67 FECFrame Minutes

Greg Shepherd, Marshal Eubanks WG chairs.

Mark Watson prsenting requirements draft update:
   draft-fecframe-req-01.txt

   - Add motivation section - RMT FEC not good enough because:
     - repeated FEC Object Transmission Information
     - different recommendations for parameters
     - formatting of stream data (eg: not transfer file with start
       and end, but stream - live without necessary start/end, limited
       delay).
   - Proposal:
     - FEC framework peer to RMT FEC building block
     - FEC scheemes in FEC-F may be different than those in RMT FEC BB

Greg asking for example -> FEC Framework for streaming content
(low latency) instead of object(file) as RMT specs assume.
break data in block, but in stream case one need different procedures.

Steve Bosco:  Q; only FEC schemes doing erasure correction in scope.  
Why ?
      Eg: Why not bitlayer correction.

A (Mark): Only UDP included as transport means no bit-errors possible
      but just packet loss. No need for bit-error correction.

A (Unidentified1):
      Only goal of group protection aganst packet loss.

A (Unidentified2):
      Other working groups are trying to provide better protection of
      UDP data beyond UDP checksum.

A (Stefan Wegner/Nokia):
      Not interested in bit error correction.

A (Colin)
     DCCP and UDP lite allow bit-errors to happen.

A (Marshal):
     What is beyond erasure correction: A (Unidentified1): Bit error  
correction
     in packet.

Q(Unidentified1):
     What is an FEC scheme:
     a) Describing of encoding
     b) how encoding is adapted to transport (UDP or RTP)
     today "scheme" meant to imply both. Maybe better to better
     differentiate between those two tasks. Not sure if document
     separation necessary for this.

A(Mark):
     Yes, may need to structure documents into these two sections.
     Want to start out with "just" FEC scheme in drafts so different
     drafts can include heir own mechanism for both components. But
     reuse of common components definitely possible/wanted.

Q(Toerless):
     What type of packet loss (low stochastic, big-burst) in scope of
     requirement

A(Mark):
     All type of losses in scope, applicability of individual proposals
     for FECs may only work for certain type of losses.

Q(Marshal)
     Ask whether it should be taken to last call.
Q(Colin)
     There seem to be things to do, do last call only after they are  
done.
A(Unidentified2):
     Do not do working group last call rightnow at all.
Q(shep):
     So we can refine requirements when we learn more through the actual
     solution drafts ?
A(Unidentified):
     Yes.
- May want to do freeze call.

Mark Watson presenting framework draft:
   draft-watson-fecframe-framework-00.txt

   - Based on original draft based on proposal made a few IETF ago in
     transport area. WHich was based on work done for 3GPP.
   - FEC streaming framework between application protos (RTP, RTCP,  
MIKEY,..)
     and Transport, Eg: UDP. FEC-framework has as module the FEC
     Scheme.
   - Application sitting on top of application protocol has
     API into controlling FEC streaming framework.
     - define which flows are to be protected. Define flows to carry
       protection data.
   - functionality of FEC streaming framework:
     - allocate packets to source blocks
     - construct and send source and repair packets
   - FEC scheme part:
     - encoding and decoding of FEC data.
     - Defines and interprets FEC signaling elements.

   - Outline whats in the draft (see slide)
     ...
     - includes possibility of unmodified sourcepackets to suppot
       fully backeward compatible FEC scheme.
       Q(Marschall): MAY ? -A(Mark): Yes.
     - Congestion control requirements

   - Comparison to 3GPP:
     3GPP fixed length symbol approach
     FEC-proposal: source blocksare sequence of tuples of flowid,  
length, data
     (eg: variable lengths)

   Q(Marshall):
     - In flute you could send any type of dsta. Are yo constrained in
       this scheme or could you send anything that goes on top of
       transport lyer (eg: UDP).
   A(Mark):
     - Yes. No assumption against transport layer protocols

   Q(Toerless)
     - Keep original Data completely unmodified ?
   A(Mark):
     - If original data is left completely unchanged, FEC scheme needs
       to be specific to application layer (eg: RTP) - eg: rely on
       referring to RTP sequence numbers in rpair stream.
       If original data is modified (tagged), then FEC scheme can be
       agnostic of application protocol.

   Q(Toerless)
     - Separation of original flow from FEC ?
   A(Mark):
     - Yes, part of the transport layer definition. Daa stream and
       repair stream: Use different ports and/or use different
       network layer addresses.

   Q(steve ?bansberg?):
     - How to manage transport addresses ?
   A(Magnus):
     - Explanation of how this works... didn't understand - ask Magnus
   A(Mark):
     - startng point is you have already source packet flow. Doesn't  
change
       when FEC is added. Same mechanism to get that transport address
       assigned may need to be aplied to repair flow as well.

   A(Marshal):
     - Should be concerned about non-simple end-to-end, eg: NAT
   A(Mark):
     - Rather not. Problem of content delivery protocol, not FEC scheme
       itself.

   - Mark continuing to present slides.

   A(Marshal):
     - Will need to worry about fragmentation in source flows when  
adding
       FEC tag-data.

   A(Colin):
     - Aware of mmusic SDP profile negotiation effort. Please inform
       mmusic of SDP implications of proposed FEC framework

   - Hum on adoption by working group. Yes hums, no no hums.

Hao Qin presenting geneic RTP Payload format draft
   draft-bsong-fecframe-gfec-00.txt

   - See slides.

   Q(Colins):
     - AVT co-chair: draft was previously presented in AVT.
       AVT rejected: conclusion that this scheme would not provide any
       benefits over RTP schemes developed by AVT. AVT told authors
       to generalize scheme and go to FEC-scheme WG.
       Q: what generalizations have been done.
   A(Hao):
     - Not author of this draft, not present at last IETF. Does notk  
now.
       answer.
   A(Stefan Wegner):
     - Would prefer not to see this draft again.
       Stop believing that interleaving solves problems.
       Assumptions based on current technology wrong in future,
       also got perfectly working RTP FEC scheme.
A(Colins):
     - This groupis doing things much broader than RTP. RTP grop (AVT)
       has already rejected it. Something needs to change about this
       draft to have any IETF progress on it.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 07 Dec 2006 18:16:10 +0100

>     - Explanation of how this works... didn't understand - ask Magnus

I can't remember what I said. I guess that this has to do with using a 
session protocol to tell which addresses and ports are used.

>   A(Mark):
>     - startng point is you have already source packet flow. Doesn't change

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------