Re: [Ekiga-devel-list] DCCP

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

Hi,

thomas schorpp wrote:
> yannick wrote:
> > Le dimanche 08 juin 2008 à 22:37 +0200, Christian Hoene a écrit :
> > > Hello,
> "...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. 
http://en.wikipedia.org/wiki/Real-time_Transport_Protocol

> 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.
> > > http://www3.tools.ietf.org/id/draft-phelan-dccp-natencap-00.txt
>
> 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).

Cheers,
--
Eugen