[Fecframe] My comments around draft-begen-fecframe-1d2d-parity-scheme-00

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 10 March 2008 22:42 UTC

Return-Path: <fecframe-bounces@ietf.org>
X-Original-To: ietfarch-fecframe-archive@core3.amsl.com
Delivered-To: ietfarch-fecframe-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9AA3A6A35; Mon, 10 Mar 2008 15:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.14
X-Spam-Level:
X-Spam-Status: No, score=-101.14 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 fOnQJqWt2zgd; Mon, 10 Mar 2008 15:42:21 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A623A6813; Mon, 10 Mar 2008 15:42:21 -0700 (PDT)
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 9A8ED3A6A35 for <fecframe@core3.amsl.com>; Mon, 10 Mar 2008 15:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 IAeIfwFjddRD for <fecframe@core3.amsl.com>; Mon, 10 Mar 2008 15:42:19 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 290853A67B6 for <fecframe@ietf.org>; Mon, 10 Mar 2008 15:41:59 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 281B52049E for <fecframe@ietf.org>; Mon, 10 Mar 2008 23:39:38 +0100 (CET)
X-AuditID: c1b4fb3e-b019cbb000004ec0-f7-47d5b8aa30e9
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0FF4B20242 for <fecframe@ietf.org>; Mon, 10 Mar 2008 23:39:38 +0100 (CET)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 23:39:37 +0100
Received: from [127.0.0.1] ([153.88.48.6]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 23:39:35 +0100
Message-ID: <47D5B8A1.9050402@ericsson.com>
Date: Mon, 10 Mar 2008 18:39:29 -0400
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: "fecframe@ietf.org" <fecframe@ietf.org>
X-OriginalArrivalTime: 10 Mar 2008 22:39:36.0782 (UTC) FILETIME=[9E8496E0:01C882FF]
X-Brightmail-Tracker: AAAAAA==
Subject: [Fecframe] My comments around draft-begen-fecframe-1d2d-parity-scheme-00
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: fecframe-bounces@ietf.org
Errors-To: fecframe-bounces@ietf.org

Hi,

In today's WG session I did appear quite negative to this draft. I am 
sorry that I wasn't better prepared and had read and thought about this 
before.

Let me try to put down my comments here and with some hindsight.

- Appropriateness in the FEC framework: Yes, this does fit the framework 
as a rather speciallized FEC code that results in one repair stream for 
every SSRC in a single RTP session. That is quite far from a more 
generic FEC scheme that can take multiple streams and combine them etc. 
   In fact it is very similar to the already existing RTP payload level 
FEC mechanisms like ULP (RFC5109). Thus, it seem to leverage very little 
of the framework and instead be very much something that could be done 
in AVT.

- The selection of RTP/UDP as repair stream transport layer. I don't 
think this really is a FEC scheme but rather a instantiation of the FEC 
framework using a component that haven't been much discussed to my 
knowledge. I do understand that it can provide feedback on how well the 
repair stream is delivered to the receiver(s). Which actually is a good 
point for general deployment. However in that case one maybe need to 
consider what general feedback that a FEC framework instance should 
provide towards the sender, i.e. including both source and repair stream 
related statistics. Something to think about and actually should make it 
way into the framework.

So I primarily would like to get the issue of the repair stream feedback 
mechanism and what the WG think is suitable for this before this is 
adopted anywhere.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecframe