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

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi,

I have reviewed the draft and finds it acceptable for a experimental RFC 
to be. From a specification point of view the text is not clear enough 
on the TFRC congestion control mechanism modifications, to be published 
as proposed in my opinion. Thus needing shape up before any publication 
as proposed in the future. Anyhow it is clear that experience on 
stability in the general Internet is needed before publication as 
something else than experimental.

Reading the draft and the simulation results I had one question which 
the draft wasn't answering at all. What happens when TCP starts using 
packet size larger than 1460 bytes in an environment where the packet 
loss rate is independent of packet size. It seems that it will result in 
similar unfairness as normal TFRC with small packets has with TCP for 
1460 bytes. Is this correct and could it be stated in the document?

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

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.

Nits:

1. In the changes section there is a claim that the abstract maximum 
length is 25 lines. According to RFC 2223bis the abstract is not 
acceptable if beyond 20 lines, with a recommend length of 5-10 lines.

2. Section 2, fourth paragraph. In the first sentence RFC 3714 is 
references. Please insert title for easier understanding on what is 
referenced.

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: magnus.westerlund at ericsson.com