IETF Logo Mail Archive

Re: [Taps] document progress update?

Vincent Roca <vincent.roca@inria.fr> Mon, 07 September 2015 07:29 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D0C1B3D06 for <taps@ietfa.amsl.com>; Mon, 7 Sep 2015 00:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.661
X-Spam-Level:
X-Spam-Status: No, score=-4.661 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5EBFsndLSRb for <taps@ietfa.amsl.com>; Mon, 7 Sep 2015 00:29:44 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F18B1B3D05 for <taps@ietf.org>; Mon, 7 Sep 2015 00:29:43 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.17,484,1437429600"; d="asc'?scan'208";a="176281432"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2015 09:29:41 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_1021A45D-8431-4B4C-9CAE-47426AD6F766"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <5C27F30C-AF58-41A1-8AB2-CDDE5CA0D7F0@trammell.ch>
Date: Mon, 07 Sep 2015 09:29:40 +0200
Message-Id: <48BCDD96-D490-4262-835E-A51F12B69174@inria.fr>
References: <CAD62q9V+kXWR26NGbOr6ZHp0N+WqmPxb_8AqSOZAgfRpMgBVLQ@mail.gmail.com> <5C27F30C-AF58-41A1-8AB2-CDDE5CA0D7F0@trammell.ch>
To: Brian Trammell <ietf@trammell.ch>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/LnjhG8nDT4n8zn8Kv-5VFWqzn98>
Cc: Aaron Falk <aaron.falk@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Vincent Roca <vincent.roca@inria.fr>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, "taps@ietf.org" <taps@ietf.org>
Subject: Re: [Taps] document progress update?
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Sep 2015 07:29:46 -0000

Hello everybody,

>> 	• Vincent Roca will write something about FLUTE based on NORM
> 
> - took a quick look at this, it looks good. Vincent also sent a suggestion that we mention FECFRAME here, though no integration-ready text.

I can provide some FECFRAME (https://datatracker.ietf.org/doc/rfc6363/) text tomorrow,
Tuesday, 8th, if you’re interested. This is not a big deal, I’m just waiting the « go ».

IMHO FECFRAME makes sense in the TAPS approach. Unlike the NORM and FLUTE/ALC
full featured protocols, FECFRAME is a shim layer that can be dynamically plugged between an
application protocol (typically RTP) and a datagram oriented transport protocol (typically UDP).
It then provides FEC protection, using one of the various FEC schemes proposed. Commercial
deployments have started and several solutions are not encumbered with IPR (at least so far).
I can tell you more if you want.

Cheers,

  Vincent

v2.23.0 | Report a Bug | By Email