[R-C] BoF approved

[John Leslie]

Bob Briscoe <bob.briscoe at bt.com> wrote:
> At 11:41 06/07/2012, Michael Welzl wrote:
>> On 6/26/12 4:05 PM, Wesley Eddy wrote:
>>> The RMCAT BoF was approved to meet at IETF 84 in Vancouver.

   From http://trac.tools.ietf.org/bof/trac/ :
] 
] Transport
] 
] RTP Media Congestion Avoidance Techniques (RMCAT)
] 
] Description: WG-forming BoF on RTP congestion control
] Responsible AD: Wesley Eddy
] BoF Chairs: Michael Welzl and Colin Perkins
] Number of people expected to attend: 100
] Length of session: 2 hours
] Conflicts to avoid: RTCWEB, AVTCORE, MMUSIC, ICCRG, CODEC, TSVWG, TCPM,
]                     CONEX, PCN, MPTCP, IPPM, CORE
] Webex: not sure
] Meetecho: not sure
] Mailing list:  rtp-congestion at alvestrand.no
] I-Ds: http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-congestion/
]       http://datatracker.ietf.org/doc/draft-jesup-rtp-congestion-reqs/
] Draft charter:
]    http://www.alvestrand.no/pipermail/rtp-congestion/2012-May/000381.html
] Status: APPROVED

>>> 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.
>>...
> 
> Michael,
> 
> Recall at the Paris ICCRG I asked the wider question of whether 
> changes to the network are in scope.

   This is Transport area, with Wes the expected Responsible AD.

   That means Network-Layer isn't expected to be in-scope for the WG.

   I would hope, however, that discussion of potential Network-Layer
work which would be helpful would be in-scope for the BoF.

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

   I expect to do a rant at the Workshop on Congestion Control for
Interactive Real-Time Communication July 28th, to the effect that this
can't be solved at the Transport Layer only.

   It looks as if enough of us will be there to discuss Bob's question.

> 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 between the two

   Clearly the first needs to be in-scope for the WG.

   IMHO the other two halves need to be discussed at the BoF.

   ;^)

--
John Leslie <john at jlc.net>