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

[Safiqul Islam <[e-mail]>]

Thanks Michael for the comments. Comments inline.


On 9. nov. 2014, at 01.18, Michael Tuexen <[e-mail]<mailto:[e-mail]>> wrote:

On 24 Oct 2014, at 14:50, Michael Welzl <[e-mail]<mailto:[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.


Okay.


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

P could also be an Integer number (e.g. Priority 1-10 instead of priority 0.1 - 1.0 ).


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

Thanks for telling us about this. We will remove this in our next version in order to avoid confusion.



* Can the algorithms work in integer arithmetic?

Yes, with some minor modifications that we recently did for coupling the LEDBAT flows. We are also planning to include this in our next update.



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

Thanks. We’ll look into it.


Regards,
Safiqul



Best regards
Michael

Cheers,
Michael



Begin forwarded message:

From: <[e-mail]<mailto:[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]<mailto:[e-mail]>>, Safiqul Islam <[e-mail]<mailto:[e-mail]>>, Stein Gjessing <[e-mail]<mailto:[e-mail]>>, Michael Welzl <[e-mail]<mailto:[e-mail]>>, Safiqul Islam <[e-mail]<mailto:[e-mail]>>, Stein Gjessing <[e-mail]<mailto:[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<http://tools.ietf.org>.

The IETF Secretariat