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

[Michael Tuexen <[e-mail]>]

On 24 Oct 2014, at 14:50, Michael Welzl <[e-mail]> wrote:

> Hi folks,
> 
> This is just to inform you that we have submitted an update of the coupled-cc draft. Since there is now some interest in shared bottleneck detection, wouldn't that be a good time to consider reading this companion document too, which describes what SBD can be good for?  :-)  => please read and comment. More information at:
> http://heim.ifi.uio.no/~safiquli/coupled-cc/index.html
> 
> This update mentions that the mechanism should also work for window-based controllers; we say this because we have some early, quite promising simulation results with LEDBAT.
Hi Michael,

I really like this ID. Some comments:

* Why do you need the first paragraph in Section 2? I don't think you use any
  RFC 2119 language in the document (There is one MAY, which doesn't need to
  be RFC 2119). Even if you do, put this paragraph in its own section.
* Why do you require the priority P in Section 5.2 to be a floating point number.
  In Section 4 you envision an FSE being implemented in a operating system kernel.
  Not all kernels support floating point operations.
* I don't understand "(including the flow itself)" since you are talking about a FG,
  not a flow, in
   In the FSE, each FG contains one static variable S_CR which is meant
   to be the sum of the calculated rates of all flows in the same FG
   (including the flow itself).
* Can the algorithms work in integer arithmetic?
* You don't describe what happens if the SBD changes a FGI of a flow.
* Maybe writing in 5.3.1 (a)
    DELTA = CC_R - FSE_R(f)
    S_CR = S_CR + DELTA
  and in 5.3.2 (a)
    if Timer is not running then
      DELTA = CC_R - FSE_R(f)
      if DELTA >= 0 then
        S_CR = S_CR + DELTA
      else // Reduce S_CR proportionally
        S_CR = S_CR * CC_R / FSE_R(f)
        Start Timer for 2 RTTs
      end if
    end if
  and stressing the point that 5.3.1 (b) and 5.3.2 (b) are equal and 5.3.1 (c) and 5.3.2 (c) are
  equal makes it simpler to get the difference between the two algorithms. But this is just
  cosmetic...

Best regards
Michael
> 
> Cheers,
> Michael
> 
> 
> 
> Begin forwarded message:
> 
>> From: <[e-mail]>
>> Subject: New Version Notification for draft-welzl-rmcat-coupled-cc-04.txt
>> Date: 24. oktober 2014 14:45:38 GMT+02:00
>> To: Michael Welzl <[e-mail]>, Safiqul Islam <[e-mail]>, Stein Gjessing <[e-mail]>, Michael Welzl <[e-mail]>, Safiqul Islam <[e-mail]>, Stein Gjessing <[e-mail]>
>> 
>> 
>> A new version of I-D, draft-welzl-rmcat-coupled-cc-04.txt
>> has been successfully submitted by Michael Welzl and posted to the
>> IETF repository.
>> 
>> Name:		draft-welzl-rmcat-coupled-cc
>> Revision:	04
>> Title:		Coupled congestion control for RTP media
>> Document date:	2014-10-24
>> Group:		Individual Submission
>> Pages:		20
>> URL:            http://www.ietf.org/internet-drafts/draft-welzl-rmcat-coupled-cc-04.txt
>> Status:         https://datatracker.ietf.org/doc/draft-welzl-rmcat-coupled-cc/
>> Htmlized:       http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-04
>> Diff:           http://www.ietf.org/rfcdiff?url2=draft-welzl-rmcat-coupled-cc-04
>> 
>> 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.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>