Re: [dccp] HEADS UP: WGLC on draft-ietf-dccp-tfrc-voip-04.txt, ends 2006-2-18

[Sally Floyd <floyd at icir.org>]

>> 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/