Michael, Recall at the Paris ICCRG I asked the wider question of whether changes to the network are in scope. I know those proposing this believe the scope is v definitely e2e protocols only (at least, if not specified down to a specific e2e protocol), but the scope determines very greatly how much of the problem we're going to solve: * If RTP-only, we don't solve TCP harming RTP, only the other way round (which is fine if that's the scope we want) * If SCTP-only, I'm not sure what we solve? * If we allow network to be in scope, we might be able to address bufferbloat-style issues, or perhaps good policer designs to protect apps from each other. My personal opinion is that this w-g should be trying to solve the problem. And the problem has three halves: * RTP harming elastic * elastic harming RTP * network arbitrating betw the two Bob At 11:41 06/07/2012, Michael Welzl wrote:
Hi all,
On 6/26/12 4:05 PM, Wesley Eddy wrote:
The RMCAT BoF was approved to meet at IETF 84 in Vancouver.
BoF chairs will be announced soon.
When it was discussed by the IESG and IAB, one topic that really needs to be clarified by/within the group is the scope of the mechanisms being developed. For instance, it needs to be more clear what stack the group wants to be chartered to operate on. Whether the group would be doing a mechanism that works for RTP itself, or a new SCTP mechanism will need to be very clear.
I would like to get a grip on exactly *what* really *is* decided regarding the way the stack looks. Which protocol over which protocol(s) for which type of data.
Any information would be appreciated - ideally with references: "... because this is in draft XY" / "... because 5 companies already implement it this way, and it's going to be in draft Z" / "...because this is what everyone in rtcweb agrees on"
- something of that sort, please. Just to get an idea of where we now stand, and what consensus we can build upon.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
________________________________________________________________ Bob Briscoe, BT Innovate & Design