[R-C] BoF approved

Bob Briscoe bob.briscoe at bt.com
Fri Jul 6 16:46:50 CEST 2012


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 at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/rtp-congestion

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 



More information about the Rtp-congestion mailing list