Re: [rmcat] New Version Notification for draft-welzl-rmcat-coupled-cc-00.txt

[Michael Welzl <[e-mail]>]

Hi Jeromy,

Thanks a whole lot for reading this and for your comments! More below -

On 6. mars 2013, at 14:12, Fu Jiantao wrote:

> Hi Michael,
> 
>    Following are my comments:
> 
>   1. multiplexing make the SBD simple, but it may take more effort for classification in QoS. delay and loss correlations works fine for UDP connection, but for having both TCP and UDP connections in police network(drop overlimit packets directly), it seems no easy way to do SDB.

As for delay and loss correlations: even that is not easy, but we're working on something there. I agree that policers may make it impossible to detect a SBD - but, for example, if flow 1 gets a lot of loss due to a policer and flow 2 doesn't, losses of the two flows won't correlate. Even if they share the same bottleneck, a correlation based scheme would then judge the flows as not sharing a bottleneck, which is a false negative and not a big problem: for all flows that are detected as not sharing a bottleneck, you have the behavior of "today".... the FSE scheme simply doesn't apply, you lose some extra benefit.


>   2. the new_S_CR seems not updated with new_CR in step 3, from the examples, it should be the new_S_CR in the last round, and I guess new_S_CR is the common state variable sharing in each round, only so it can be used to avoid only make S_CR increase at once.

No, new_S_CR is really a temporary variable. Maybe we should have called it tmp_S_CR...
new_S_CR is the newly calculated sum, as a result of all the current CR values in the FSE. S_CR however is a historical stored value per flow, which is updated every time the flow enters step 3. Thus, if new_S_CR is different from S_CR, some other flow Y has changed its CR since the last time flow X has gone through step 3.


>   3. The example algorithm will only update flow(i)'s state when its cc changed the calculated rate, other flow's state is leave untouched. There are other algorithms, for example, updates all flow's state when flow(i)'s state changed. What's the reason to prefer the first one, and I think the second one is more reasonable and simple to implement.

I'm used to congestion controllers that update their rate all the time, this guided my thinking. Maybe that's wrong for rmcat, where feedback is minimized... I also thought that this is the simplest approach, but maybe it's just fine to change a rate even when the controller doesn't do anything to it. We'll have to consider that. Anyway, the main point here is to come up with something simple and working. There are something between 7000 and 9000 possible improvements to this, I guess   :-)

Thanks again,

cheers,
Michael


> 
> Thanks
> 
> Jeromy
> 
> 
> 2013/1/19 Michael Welzl <[e-mail]>
> Hi all,
> 
> See below the announcement of a draft I just posted, to address the milestone on "identifying and controlling groups of flows".
> I'm curious to hear your thoughts!
> 
> Cheers,
> Michael
> 
> 
> Begin forwarded message:
> 
> > From: [e-mail]
> > Subject: New Version Notification for draft-welzl-rmcat-coupled-cc-00.txt
> > Date: January 19, 2013 10:56:14 AM GMT+01:00
> > To: [e-mail]
> >
> >
> > A new version of I-D, draft-welzl-rmcat-coupled-cc-00.txt
> > has been successfully submitted by Michael Welzl and posted to the
> > IETF repository.
> >
> > Filename:      draft-welzl-rmcat-coupled-cc
> > Revision:      00
> > Title:                 Coupled congestion control for RTP media
> > Creation date:         2013-01-19
> > WG ID:                 Individual Submission
> > Number of pages: 14
> > URL:             http://www.ietf.org/internet-drafts/draft-welzl-rmcat-coupled-cc-00.txt
> > Status:          http://datatracker.ietf.org/doc/draft-welzl-rmcat-coupled-cc
> > Htmlized:        http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-00
> >
> >
> > Abstract:
> >   When multiple congestion controlled RTP sessions traverse the same
> >   network bottleneck, it can be beneficial to combine their controls
> >   such that the total on-the-wire behavior is improved.  This document
> >   describes such a method for flows that have the same sender, in a way
> >   that is as flexible and simple as possible while minimizing the
> >   amount of changes needed to existing RTP applications.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> 
>