[R-C] BoF approved

[Michael Welzl]

I agree.

It seems clear to me that the ability to work everywhere is the top  
goal of rtcweb; interactions with the network have to be considered,  
of course (any congestion control algorithm will have to consider  
queue behavior).

More below, in line:


On Jul 6, 2012, at 6:20 PM, Bill Ver Steeg (versteb) wrote:

> I agree that this is not the right forum for discussing middlebox  
> buffer management algorithms. I would add that even if the network  
> elements do creep into scope, the host-based congestion control  
> algorithms still have to work with the existing systems found in the  
> wild. In other words, we could suggest that the middleboxes  
> implement [insert your favorite AQM algorithm here]and [insert your  
> pick of ECN, PCN, or maybe even Conex, etc] but the hosts still need  
> to deal with [tail drop, RED, WRED, etc].
>
> Stated another way, the algorithm is going to get a variety of  
> congestion signals. When running on networks with primitive buffer  
> management algorithms, one of those signals is going to be delay. On  
> more modern systems, we can hope that the middleboxes' buffer  
> management algorithms do not introduce persistent delay.
>
> So, the RMCAT work will have to consider delay, packet loss and  
> explicit packet markings. In a perfect world, the network will never  
> give us persistent delay - but the world is rarely perfect.
>
> Bill VerSteeg
>
> -----Original Message-----
> From: rtp-congestion-bounces at alvestrand.no [mailto:rtp-congestion-bounces at alvestrand.no 
> ] On Behalf Of John Leslie
> Sent: Friday, July 06, 2012 11:38 AM
> To: Bob Briscoe
> Cc: rtp-congestion at alvestrand.no; Michael Welzl
> Subject: Re: [R-C] BoF approved
>
> 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.

Personally, for the sake of keeping focus, I would say it's out of  
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)

I don't understand that.


>> * If SCTP-only, I'm not sure what we solve?

I get the impression that SCTP-only is not an option.


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

Good policer designs that work well with rtcweb would be cool to have,  
but why can't that be done e.g. in ICCRG?


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

I agree, but I think we should try to get consensus on some key issues  
earlier than that.


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

If I understood it correctly, Matt Mathis argued that neither the  
first nor the second should be in scope. I'd like to hear some more  
views on that.

Having read RFC5434, I think a general goal, and the role of Colin and  
me, is to try to maximize consensus and minimize the amount of  
discussion-at-the-BOF beforehand.
So naturally I disagree, for now, that these things need to be  
discussed there. Let's try to agree on as much as possible before it.

Cheers,
Michael