RE: DCCP for VoIP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux