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


_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Reply via email to