Re: [Fecframe] FECFrame WG Minutes IETF 75
Ye-Kui Wang <yekuiwang@huawei.com> Mon, 31 August 2009 15:44 UTC
Return-Path: <yekuiwang@huawei.com>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED223A6B6C for <fecframe@core3.amsl.com>; Mon, 31 Aug 2009 08:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.559
X-Spam-Level:
X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L15M8U3c3Zx5 for <fecframe@core3.amsl.com>; Mon, 31 Aug 2009 08:44:41 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 85F4D28C315 for <fecframe@ietf.org>; Mon, 31 Aug 2009 08:42:41 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP8001Z5ZNG4V@usaga04-in.huawei.com> for fecframe@ietf.org; Mon, 31 Aug 2009 10:42:52 -0500 (CDT)
Received: from W90946 ([10.193.125.102]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP800GNYZNAVE@usaga04-in.huawei.com> for fecframe@ietf.org; Mon, 31 Aug 2009 10:42:52 -0500 (CDT)
Date: Mon, 31 Aug 2009 11:42:46 -0400
From: Ye-Kui Wang <yekuiwang@huawei.com>
In-reply-to: <38c19b540908261210o2603c144j32367830f91bc2b6@mail.gmail.com>
To: gjshep@gmail.com, fecframe@ietf.org
Message-id: <6BC63A2C527148E3937AA11C49CCE339@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: quoted-printable
Thread-index: AcomgQf6mVOnTjT9RYu4STOa9Q/KAwD0CYcw
References: <38c19b540908261210o2603c144j32367830f91bc2b6@mail.gmail.com>
Subject: Re: [Fecframe] FECFrame WG Minutes IETF 75
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 15:44:43 -0000
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: fecframe-bounces@ietf.org > [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd > Sent: Wednesday, August 26, 2009 3:11 PM > To: fecframe@ietf.org > Subject: [Fecframe] FECFrame WG Minutes IETF 75 > > 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 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >
- [Fecframe] FECFrame WG Minutes IETF 75 Greg Shepherd
- Re: [Fecframe] FECFrame WG Minutes IETF 75 Ye-Kui Wang
- Re: [Fecframe] FECFrame WG Minutes IETF 75 Ye-Kui Wang
- Re: [Fecframe] FECFrame WG Minutes IETF 75 Watson, Mark
- Re: [Fecframe] FECFrame WG Minutes IETF 75 Ali C. Begen (abegen)
- Re: [Fecframe] FECFrame WG Minutes IETF 75 Watson, Mark
- Re: [Fecframe] FECFrame WG Minutes IETF 75 Ali C. Begen (abegen)
- Re: [Fecframe] FECFrame WG Minutes IETF 75 Greg Shepherd