Hi Michael, I am not sure if it is right time to give you this feedback, but just in case if it helps. So, here goes another comments about this draft. Overall, IMHO, it looks like a nice idea if we could have an option to emulate multiple TFRC flows for a single application without causing any harm to other services. However, as Gorry mentioned earlier, I am not sure (yet) what kind of applications can be benefit out of mulTFRC - the application section (Section 3.1) doesn't look so clear. 1) I didn't properly understand how you have derived the equation in the draft, mostly in Section 2.1 except the well-known TCP throughput equation. So to speak, I understood the point of limiting N to 6 as described in Section 3.2., but I didn't understand where the number "12" came from at the equation in Section 2.1 (where the 'af' variable is determined). Similarly, the rest of the temporary floating variable calculations, I didn't quite understand. Would it be possible to include a reference if you have a reason not to explain the detailed explanation? 2) In Section 2.1., you have used RFC 2988 to calculate RTO. It is well known that this method is more accurate when calculating RTO than the one used in the original TFRC draft (RFC5348). To be able to use the method in RFC 2988, it has to be a sender-driven congestion control mechanisms, because it is hard to measure RTT variance for a receiver-driven mechanism. As we know, TFRC is a receiver-driven CC, hence it had to approximate the RTT measurement process, and couldn't directly apply the method described in RFC 2988. I presume that mulTFRC is also a receiver-driven mechanism. Then, how did you apply RTO calculation mechanism (RFC 2988) to mulTFRC? Also, do you measure RTT/RTO per flow? It would be nice if you could describe RTT/RTO measurement process(es) in more detail. 3) Maybe, this could be a typo, or I misunderstood something. I think the equations in Section 2.3 have some typos. Please ignore me if I'm wrong - these are mainly about indexes. The first algorithm in Section 2.3., I think (w_i) should be read w_(i-1) in the "Else" statement. Likewise, the index (i = 0 to k-1) at "for" statement in "If" statement should be read (i = 1 to (k-1)). I will get back to you again as I come up with more feedback. Cheers, Soo-Hyun On Wed, Oct 7, 2009 at 14:08, Michael Welzl <michawe@xxxxxxxxxx> wrote: > Dear all, > > We submitted a minor update of our draft yesterday, > http://www.ietf.org/id/draft-welzl-multfrc-01.txt > > We have more material - background reading, simulation code, > real-life code, available via: > http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html > > ...and would greatly appreciate any comments on this list. > (thanks to Gorry for already commenting - I'll answer this in a > separate email) > > Cheers, > Michael > > > > A new version of I-D, draft-welzl-multfrc-01.txt has been successfuly > submitted by Michael Welzl and posted to the IETF repository. > > Filename: draft-welzl-multfrc > Revision: 01 > Title: MulTFRC: TFRC with weighted fairness > Creation_date: 2009-10-06 > WG ID: Independent Submission > Number_of_pages: 13 > > Abstract: > This document specifies the MulTFRC congestion control mechanism. > MulTFRC is derived from TFRC and can be implemented by carrying out a > few small and simple changes to the original mechanism. Its behavior > differs from TFRC in that it emulates a number of TFRC flows with > more flexibility than what would be practical or even possible using > multiple real TFRC flows. Additionally, MulTFRC better preserves the > original features of TFRC than multiple real TFRCs do. > > > > The IETF Secretariat. > > > >
