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

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

 



Hi,

(sorry for breaking thread...)
I have some comments on MulTFRC draft.
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. )

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

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

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.

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)

- Michio


[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