Re: [Ekiga-devel-list] DCCP


thomas schorpp wrote:
yannick wrote:
Le dimanche 08 juin 2008 à 22:37 +0200, Christian Hoene a écrit :

"...Problem Statement for [DCCP]", which discusses such questions as "why not just implement congestion control at the application layer?"

This is because it is not so simple to create a congestion control. Why do you think that no other VoIP application has a CC? Articles write that many applications create CC themselves and their CC is not TCP-friendly.

Second, the application needs to add a thread, which continuously listen for ack, so this complicates the application. Also, it is (much) slower and imprecise than putting it in the kernel (hence transport layer), because sending or receiving a packet is not done exactly at the correct time, since linux changes the executing thread at non precise times (it is not real-time). Practically, it seems to me impossible to write an *application* which sends a packet *exactly* when an ack has been received.

RTP is in user space and is at application layer, cf.

and "why not SCTP?"

Snark? TheBonsai?

One drawback of SCTP is that it uses TCP CC, while in DCCP the CC can be chosen. For ex. there is TCP-like and TFRC, the last one seems to be interesting for streaming. What does SCTP offer than DCCP does not?

-so only a partial solution of a becoming less "potential" problem due
to advances
with codecs which will slow down excessive UDP traffic.
Yes, both the codec and the DCCP must work hand-in-hand. If DCCP tells, that the link is congested, the codec must slow down its coding rate.

codecs could implement their own congestions detection protocols on their layer, etc.
but i tend to agree finally to leave this to a open standard like DCCP :)

Codecs are for compressing data on a host, not for transmitting it on the network, processing acks etc.

It's not only because it's open, but it's a state of the art...

-most soho embedded routers and firewalls are based on very old linux
kernels without DCCP-
support and the DCCP wikipedia article states not much implementations
since years.
The current solution for NATs is to use DCCP on top of UDP.

basically ISO/OSI- layer violation? see above.

I do not think so. First, DCCP can be put above UDP and still be a transport protocol. Layer violation means, IIUC, that one layer "gets into" (?) another layer. Here, it's just encapsulation, similar to IPv6 inside IPv4. Second, this is a temporary solution, I saw 1-2 months ago (I lost the link) that NAT on linux (masquerading) added support for DCCP.

For the moment, IIUC, ekiga uses the parameter in prefs->video->codecs statically, i.e. at the beginning of the connection. Why not change it dynamically, during the connection? It would become useless for the user in this case, as it adapts itself. The question is: can the codec change the encoding bitrate during the transmission?

If someone knows how to make the codec change the bitrate during the transmission, I would be glad to add the code for DCCP in ekiga and inform the codec about the bandwidth changing (to be confirmed after evaluating the work and thinking twice, probably this summer).


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