Re: Comments on MulTFRC (draft-welzl-multfrc-00)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Michio,

Thanks for your comments!


I guess the IETF needs to establish the criterion and principle of N-TCP-friendliness before MulTFRC going ahead. Otherwise, MulTFRC couldn't fit the current Internet safely, dealing with TCP-friendliness (i.e., you limit the N to 6, but it's obviously unfair in TCP-friendly manner. )
I think we have some form of agreement that strictly requiring
TCP-friendliness is not a way forward already - cf. the
"Internet Capacity Sharing Architecture" design team:
http://tools.ietf.org/group/irtf/trac/wiki/CapacitySharingArch
(although this is only an IRTF activity, and not a very active
one so far... )

About the limit, we recommend to make N=6 a system-wide
limit for MulTFRC based flows; if it's implemented in this way,
it's never more aggressive than 6 parallel TCP flows are, and
that puts it in line with TCP in very common usage scenarios
(e.g. with p2p apps opening multiple (many more) connections).


In addition, it would be better to describe more implication with DCCP ***protocol***, for example, requirement for the protocol specification. Otherwise, MulTFRC might look similar to other congestion control specifications (e.g., Highspeed TCP)...

Our intention *is* to first describe a congestion control spec, just like
the TFRC spec, and then follow up with a CCID, just like CCID-3.


About the Sec.3.2 (and other), how N should be set, the draft says the maximum value of N should be 6 in the form of the utilization of the bottleneck. However, it would not be make sense to fill up the bottleneck utilization by large N. (i.e., bad utilization of the bottleneck is a separate problem from MulTFRC).
I don't understand this statement. What do you mean? Why is this a separate problem?


In addition, the description of how to use MulTFRC is not clear. (briefly described only at the beginning of Sec. 3.1). For example, description such as "The users that ISP allows to use twice traffic can set N to 2" is helpful.
Thanks; we'll try to make this description clearer in the next update.


And about the equation, isn't it too complicated? (e.g., I wonder using square root might be problematic in some cases on the kernel implementation)

Well - it's as simple as we could make it. I doubt that it would cause
major calculation problems (and square roots are also a part of
the original equation used by TFRC).

Cheers,
Michael



[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux