>> Yep. Though I don't trust all small-packet TFRC applications to >> have is a user who hangs up when the packet drop rate gets to be too >> high... > >I agree that we can't rely on the user to react to this correctly. My >comment is more saying that this is way beyond the expected normal work >regime of the applications. Applications may try to operate in this >environment and must not cause harm. Sally, in your opinion is the >TFRC-PS causing harm in this regime or is it a decently well behaving >internet citizen?
Well, in an environment where large and small packets are equally likely to be dropped, I think that TFRC-PS is a decently behaving internet citizen. In an environment where small packets are less likely to be dropped than large packets, and all of the packets are small packets, I think that TFRC-PS is a plausibly behaving internet citizen, but that plain TFRC would be even better (because for a given amount of per-flow bandwidth, plain TFRC would manage it with a slightly lower packet drop rate, because it has a different response function than TFRC-PS). I will try to add something to the draft comparing the response function of TFRC with the response function of TFRC-PS. In an environment where small packets are less likely to be dropped than large packets, and there is a mix of large and small packets, and high congestion, the large packets could end up getting most of the packet drops, and a corresponding small fraction of the link bandwidth. But the problem wouldn't be one of congestion collapse, more one of fairness (or the lack of fairness) with the large-packet flows. I can also try to add more scenarios to the draft illustrating this, showing the fraction of link bandwidth going to the M large-packet TCP flows, and the fraction of link bandwidth going to the N small-packet TFRC-PS flows. - Sally http://www.icir.org/floyd/
