Re: [Taps] document progress update?

I'd have thought it was worth seeing if FECFRAME fits as something to 
talk about.

It is used in places. There are transport concerns that differ and could 
be highlighted  - because some uses require pre-provisioned capacity 
(aka, do not have CC), so we probably need to say something about 
managed environments.

Whether it is a transport protocol (like TCP, UDP, websockets, etc), or 
a component (like ledbat) could be an interesting first debate.

What do others think?

Gorry

On 07/09/2015 08:29, Vincent Roca wrote:
> 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
>
>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>