Subject: [Taps] document progress update?

From: Aaron Falk <[email-masked]>
Date: Thu, 3 Sep 2015 15:09:00 -0400

TAPS Editors-

Can you provide an update on the draft revisions discussed in Prague?  We
discussed a webex interim meeting to get review and hopefully some
consensus.

>From the minutes I have the following changes (this may not be complete):

   - Karen & Michael will add some text on SCTP
   - Varun will add some text on RTP
   - Brian will revert the TCP text to remove component/feature ("keep
   3.1.1, 3.1.2, strike 3.1.3, replace 4 with a list of features we'd like to
   have...? [Brian knows what to do :-)]."
   - Vincent Roca will write something about FLUTE based on NORM
   - Gorry will write something on applications learning about network
   conditions (ICMP)
   - Mirja will write something about scavenger congestion control

--aaron

---

From: Brian Trammell <[email-masked]>
Date: Thu, 3 Sep 2015 21:12:54 +0200

hi Aaron,

the status is pretty much "August is over and people are finally back from vacation, and are dusting off their inboxes."

On specific points:

> On 03 Sep 2015, at 21:09, Aaron Falk <[email-masked]> wrote:
> 
> TAPS Editors-
> 
> Can you provide an update on the draft revisions discussed in Prague?  We discussed a webex interim meeting to get review and hopefully some consensus.
> 
> 	• Karen & Michael will add some text on SCTP

- will twist arms tomorrow or Tuesday.

> 	• Varun will add some text on RTP

- ditto.

> 	• Brian will revert the TCP text to remove component/feature ("keep 3.1.1, 3.1.2, strike 3.1.3, replace 4 with a list of features we'd like to have...? [Brian knows what to do :-)]."

- just needs to be done, on the list for next week.

> 	• 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.

> 	• Gorry will write something on applications learning about network conditions (ICMP)
> 	• Mirja will write something about scavenger congestion control

- will leave these to Gorry and Mirja to answer.

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 3 Sep 2015 21:14:56 +0200

>> 	• Varun will add some text on RTP

Karen, Michael, Varun, consider your arms publicly twisted. :)

Cheers,

Brian

---

From: Aaron Falk <[email-masked]>
Date: Thu, 3 Sep 2015 15:19:58 -0400

Thanks for the quick update, Brian!

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 3 Sep 2015 23:05:36 +0200

> On 03 Sep 2015, at 21:14, Brian Trammell <[email-masked]> wrote:
> 
OK. So if you are twisting my arm, please state clearly what you want me to write...
Seriously: I'm willing to provide SCTP related text as long as I know what
you want. However, I don't. I think Mirja wanted to look at the document
and come back with a statement about what is missing or could be improved.

So do you have any particular things you want to be added or changed?

Best regards
Michael
> 
> Cheers,
> 
> Brian
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Vincent Roca <[email-masked]>
Date: Mon, 7 Sep 2015 09:29:40 +0200

Hello everybody,

> - 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 24 Sep 2015 10:07:23 +0100

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