Thanks for the response (also thanks to Vlad). My take is then that the best current alternative is CCID-4 TFRC-SP like with FR. Some extra questions however. 1) What is the definition of large idle period, my feeling is that in normal sendrecv operation in a VoIP the largest gap between packets is in the order of 500ms, for AMR it is ~150ms. Call on hold situations may however lead to long idle periods. 2) How often is feedback sent? (sorry for a question that I should probably answer myself by means of some RTFM) but if you could answer it I would really appreciate it. Regards Ingemar > -----Original Message----- > From: Arjuna Sathiaseelan [mailto:arjuna@xxxxxxxxxxxxxx] > Sent: den 15 augusti 2007 15:01 > To: Ingemar Johansson S (LU/EAB); ''dccp' working group' > Cc: 'Gorry Fairhurst' > Subject: RE: DCCP for VoIP > > Dear Ingemar, > Let me try to answer you using my novice "simulation" > experience with VoIP over DCCP :). > > As of now we have three main CCID's: > > 1) CCID-2: TCP like > 2) CCID-3: TFRC like > 3) CCID-3 TFRC-SP like > > Then we have extensions which could become "experimental" > standards such as Faster Restart (FR) for DCCP and > Quick-Start (QS) for DCCP. > > Now lets try to do an act of segregation :). > > 1) CCID-2: TCP like > > During the recent days, I have been doing some simulations > for VoIP (G.711 codec, Tx buffer = 5 packets) using CCID-2, > and found some interesting performance results. The results > could be classified into two: > > a) Without loss > Without loss, the R-Score performance of CCID-2 > (assuming CCID-2 uses RFC 2861 for congestion window > validation during datalimited/idle periods) for VoIP is > relatively similar to CCID-4 (with revisions based on the > latest 3448-bis draft) and CCID-4 FR for datalimited periods > (in the range of burst = 0.352s and idle = 0.65s) and better > when the datalimited periods are in the range of ( >= burst = > 2.0s and idle = 2.5s) > > So what leads to this performance improvement of CCID-2? My > belief is that as CCID-2 is bursty rather than being rate > paced, the packets in the Tx buffer are immediately sent > rather than being queued up and sent at fixed intervals. > This leads to reduction of Tx buffer drops and hence a > performance improvement. > > > b) With loss: > But with loss, CCID-2 performs the worst! The reason > which is very clear is that with a loss, the cwnd is due to > the drastic reduction of the cwnd (cut into half) and then > the slow linear increase back to the original window. > > So my thought is CCID-2 is not suitable for any > conversational class - but may be suitable for some > walled-garden type of network where you have suitable QoS. > Moreover, you want to reduce the feedback rate, so we've got > to isolate CCID-2. > > 2) CCID-3: TFRC like > > CCID-3 could be used with VoIP, but then as RFC 3448 states: > > " TFRC is designed for best performance with applications > that use a > fixed segment size, and vary their sending rate in packets per > second in response to congestion. TFRC can also be used, perhaps > with less optimal performance, with applications that don't have a > fixed segment size, but where the segment size varies according to > the needs of the application (e.g., video applications)." > > So based on your requirements where you want to reduce the > packet size during congestion, we need to isolate CCID-3 too.. > > 3) CCID-4: TFRC-SP like > > RFC 4828 states: > > "This document instead specifies TFRC-SP, a variant of > TFRC designed for > applications that send small packets, where applications > could either > have a fixed or varying packet size or could adapt their > packet size > in response to congestion" > > TFRC-SP addresses the issues of fairness when small packets > of the VoIP flow have to compete with the large packets of > large TCP flows. > > From my simulation experience, what I saw was CCID-4 (with > the latest revision of 3448-bis) does give good performance > when coupled with an experimental mechanism such as Faster > Restart. CCID-4 alone can give good performance for > datalimited periods whereas for large idle periods we need a > mechanism such as FR..This applies for both with and without loss. > > Ofcourse there maybe problems when VoIP over DCCP is used > over large delay networks but with appropriate QoS mechanisms > we could achieve reasonable perceived quality. > > I am not sure if this reply answers your questions :). Sorry > for the large reply :) > > Regards > Arjuna > > > > > -----Original Message----- > > From: Ingemar Johansson S (LU/EAB) > > [mailto:ingemar.s.johansson@xxxxxxxxxxxx] > > Sent: 15 August 2007 12:49 > > To: 'dccp' working group > > Subject: DCCP for VoIP > > > > Hi > > > > I am trying to get a deeper understanding of the DCCP protocol. > > However I am a little lost on the different CCID's. > > > > I have a typical VoIP scenario where packets are transmitted 50 > > packets per second with a payload size of ~30bytes. Also one can > > assume that DTX is used and that periodic comfort noise > update packets > > are transmitted at a rate of ~5 packet/second. > > > > In terms of congestion avoidance it is possible to reduce > the payload > > size to 10bytes and the packet rate can be reduced to 10 > packets/second. > > It is not acceptable to reduce the packet rate to below 10 > > packets/second for active speech segments. > > > > An additional requirement is that the feedback rate must be kept > > fairly low. > > > > Given the outline above. What CCID can be used ?. > > Two drafts catch my interest, namely > > http://tools.ietf.org/wg/dccp/draft-ietf-dccp-tfrc-faster-restart/ > > And > > http://tools.ietf.org/wg/dccp/draft-floyd-dccp-ccid4-01.txt > > Do any of the above meet the requirements ? > > > > Regards > > Ingemar > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" > > EAB/TVP - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Luleå, Sweden > > Tel: +46 (0)8 4043042 > > ECN: 850-43042 > > Mobile: +46 (0)730 783289 > > MSN: ingemarjohansson1965@xxxxxxxxxxx > > ******************************************* > > > > > > >
