[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [dccp] DCCP for VoIP
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 at erg.abdn.ac.uk]
> Sent: den 15 augusti 2007 15:01
> To: Ingemar Johansson S (LU/EAB); ''dccp' working group'
> Cc: 'Gorry Fairhurst'
> Subject: RE: [dccp] 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 at ericsson.com]
> > Sent: 15 August 2007 12:49
> > To: 'dccp' working group
> > Subject: [dccp] 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 at hotmail.com
> > *******************************************
> >
> >
>
>
>