Sally Floyd wrote:
...
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.
Okay, that explains it. I agree a note on this would be good.
Also my believe is that the behavior beyond 25% packet loss
is of less importance as long as it doesn't lead to congestion collapse.
TCP may still get some data through in that range, but most real-time
DCCP applications would stop being useful in that regime.
The possibility to run VoIP when having packet loss is much dependent on
the codec and used robustness methods. However most encoded content
without any redundancy will start to provide significantly reduced
quality at 1-5% frame loss rate. Redundancy methods are effective but
also increases bit-rate significantly. The delay will also increase with
at least one packetization interval, thus more than 10ms for TFRC-SP.
Also codecs are vulnerable to burst losses and would still have issues
with significantly elevated packet loss rates.
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?
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?
Isn't it easier to negotiate if it is given its own CCID? Using yet
another level of negotiation seems counter productive and may increase
the delay.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED]
