Hi Soo-Hyun,
Thank you for your comments.I wrote some answers in the text below
Soo-Hyun Choi schrieb:
> 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.
>
>
Michael answered the comment from Gorry and he pointed out that MulTFRC
could make DCCP more attractive for the application developers. It would
be interesting to hear more feedback on that.
> 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?
>
There are two references which explain equation and the MulTFRC protocol:
[Dam+08] Damjanovic, D., Welzl, M., Telek, M., and W. Heiss,
"Extending the TCP Steady-State Throughput Equation for
Parallel TCP Flows", University of Innsbruck, Institute of
Computer Science, DPS NSG Technical Report 2, August 2008.
[Dam+09] Damjanovic, D. and M. Welzl, "MulTFRC: Providing Weighted
Fairness for Multimedia Applications (and others too!)",
ACM SIGCOMM Computer Communication Review vol. 39, issue 9
(July 2009), 2009.
the number "12" is explain in the second one. Actually in the case the
"n" parameter is limited to 6 this is not important. It is important
only if "n" is larger than 12 (the MulTFRC can work for larger values too)
> 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.
>
>
In original TFRC draft (rfc 5348), the rate is calculated at the sender.
The sender receives from the receiver only the loss rate measurement -
"p" and it calculates RTT and RTO and use it for the rate calculation.
The RTO calculation from rfc 2988 can be used.
> 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)).
>
>
Thank you for this remark; it is a typo. I will update it .
Cheers,
Dragana
> 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.
>>
>>
>>
>>
>>
>
>
