...
I was also somewhat concerned with the table 14 behavior of TFRC-SP. I
think this is one of the few really problematic cases I have seen. In
all other graphs the TFRC-SP loss rates continue to raise and the
unfairness seems to stay within non-critical (less than factor of 10)
for packet loss rates that are usable for a VoIP client (less than
5-10%). But the fact that the packet loss rates drops to lower results
than the least congested case in that graph makes me worried for the
stability.
Yep. I believe that the answer is that this drop rate (55%
for the TCP traffic) has exceeded the adaptive range of Adaptive RED.
In NS, Adaptive RED is configured not to "adapt" to packet drop
rates over 50%. When the packet drop rate is at most 50%,
Adaptive RED is moderately successful in keeping the packet drop
rate proportional to the packet size - TCP packets are six times
larger than the TFRC-SP packets (including headers), so the TCP
packets should see a packet drop rate roughly six times larger.
But for packet drop rates over 50%, Adaptive RED is no longer
in this regime, so it is no longer successful in keeping the
drop rate for TCP packets at most six times the drop rate of
the TFRC-SP packets. So this behavior is about the details of
the Adaptive RED implementation in NS, and not about TFRC-SP.
I will add a note about this to the draft.
What is the plans for defining a DCCP CCID for TFRC-SP? It would seem
that only defining the algorithm does allow only for where limited
tests. Assigning a experimental CCID for TFRC-SP would allow more wide
scale experiments.
Yep, that comes next. Hopefully it will be a one-page document.
In terms of implementation, the small-packet variant of TFRC
would be implemented as a small modification to CCID3, with the
modifications as described in Section 3 of the draft. This involves:
(1) using 1460 bytes at the nominal packet size;
(2) reducing the allowed transmit rate by
X := X * s_true / (s_true + H),
for s_true the true packet size and H the estimated header size;
(3) maintaining a minimum interval of 10 ms between packets; and
(4) using a modified method for measuring the loss event rate for
loss intervals at most two RTTs long.
So this could be either a new CCID, or a negotiated variant of CCID3.
In terms of implementation, I think it makes more sense to think of
it as a negotiated variant of CCID3, but in terms of API interfaces,
it is probably more straightforward to present it as a new CCID.
Yes? No?