[dccp] Re: status of available DCCP implementations?

[Arnaldo Carvalho de Melo <acme at conectiva.com.br>]

Em Thu, Jun 16, 2005 at 11:59:28AM +0200, Lars Eggert escreveu:
> Hi,
> 
> now that the DCCP base spec and profiles have solidified, it may be  
> interesting to gain some more experimental experience with DCCP. If  
> you have implemented DCCP, are implementing it or plan on  
> implementing it, we'd like to hear from you!
> 
> Specifically, we'd like to know about:
> 
> - state of the implementation
>    - version(s) of the draft(s) implemented

latest ones

>    - if you don't implement the latest yet, do you plan on doing so?
>    - unsupported features - anything you plan on leaving unsupported?

No, but for now only CCID3 is being implemented, in cooperation with Ian
McDonald @ Waikato

There is also a initial pluggable CCID3 infrastructure using Linux kernel
loadable modules that automatically load the request ccid module, ah for
now options negotiation is not implemented, i.e. not ready for interop
yet, but works with default values.

> - availability
>    - license

GPL

>    - platform

Linux 2.6

>    - planned release date if not released

Huh? what is that? :-) I have it always available at:

http://oops.ghostprotocols.net:81/cgi-bin/viewcvs.cgi/dccp-2.6/

> - lessons learned
>    - experimental/performance results

I slowed down DCCP development for a while to work on a tool to collect
callgraphs, its name is OSTRA, its availabe in a git (Linus Torvalds SCM
core) repository at:

http://www.kernel.org/git/?p=linux/kernel/git/acme/ostra.git;a=tree

There you'll find READMEs, etc, anyway, the DCCP callgraphs for sessions
over loopback using a ttcp patched to support DCCP is at:

http://oops.ghostprotocols.net:81/ostra/dccp_client_ttcp_ccid3_usecs/
http://oops.ghostprotocols.net:81/ostra/dccp_client_ttcp_ccid3_usecs_new/
http://oops.ghostprotocols.net:81/ostra/dccp_listen_ttcp_ccid3_usecs/
http://oops.ghostprotocols.net:81/ostra/dccp_server_ttcp_ccid3_usecs/

Looking at these callgraphs can provide a good picture of the current
state of this DCCP implementation, it tracks most of the connection
state, with all of the hctx and hcrx fields showed at all the lines, etc.

The tool also automatically generates plottings for all of the fields
being collected, for instance:

http://oops.ghostprotocols.net:81/ostra/dccp_client_ttcp_ccid3_usecs/hctx_x.png
http://oops.ghostprotocols.net:81/ostra/dccp_client_ttcp_ccid3_usecs/hctx_x_recv.png
http://oops.ghostprotocols.net:81/ostra/dccp_client_ttcp_ccid3_usecs/hctx_t_ipi.png
http://oops.ghostprotocols.net:81/ostra/dccp_client_ttcp_ccid3_usecs/hctx_rtt.png
http://oops.ghostprotocols.net:81/ostra/dccp_client_ttcp_ccid3_usecs/hctx_t_rto.png
http://oops.ghostprotocols.net:81/ostra/dccp_client_ttcp_ccid3_usecs/hctx_last_win_count.png

The changes page shows the first samples and has links to all the
plottings:

http://oops.ghostprotocols.net:81/ostra/dccp_client_ttcp_ccid3_usecs/changes.html

For those that are still reading there is also an OSTRA trace for a TCP
session transferring a 39 MB linux tarball to the master.kernel.org
machine using the default congestion control in Linux 2.6, BIC:

http://oops.ghostprotocols.net:81/ostra/ostra-trace-of-scp-linux-2.6.11.tar.bz2-to-master.kernel.org/

>    - API issues
>    - application behavior/compatibility
 
> - interest in participating in an eventual interop event

Yes.

> Thanks,
> Lars
> -- 
> Lars Eggert                                     NEC Network Laboratories
> 



-- 


                        - Arnaldo