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
