Todo list for DCCP

WikiGnomes - do not change this into a numbered list. These items often reference other items. This should really be in something like BugZilla but I am lazy -- IanMcDonald

See also http://developer.osdl.org/shemminger/wiki/index.php/TODO#DCCP as the maintenance of status of DCCP is going to shift to OSDL

4 - implement CCID2 and other experimental CCIDs.
7 - get DCCP support into upstream ethereal. Joacim working on.
10 - Feature negotiations. Joacim raised.
18 - Go through and review fixme/bug comments in code.
22 - Look at sharing code with TCP Congestion code. Raised by ArnaldoMelo.
24 - Implement the remaining options processing
25 - Implement iptables header matching for DCCP. Status Harald Welte attached an (untested) patch for basic iptables support. Please review (esp. the option matching part) and consider applying it to your tree (or tell me to submit it to davem). Current iptables from svn.netfilter.org has the required userspace support (and even a manpage snippet).
26 - Implement connection tracking and NAT for DCCP in netfilter/iptables. To the best of my knowledge, we're the only stateful packet filter that does SCTP so far... would be great to have DCCP support, too. Since you know the state transitions and other aspects of the DCCP protocol well, it would be great to see ip_conntrack_proto_dccp.c (or even better: nf_conntrack_proto_dccp.c) at some point. Requested by Harald Welte.
31 - Get an OOPS on module unload of dccp_ccid3 and dccp together. Notified by IanMcDonald. ArnaldoMelo has supplied a patch. Low priority.
32 - Look at changing away from struct timeval/do_gettimeofday as these waste 4 bytes per instance on 64 bit machines. Raised by ArnaldoMelo
35 - One thing that I found out is that we're not accounting the packet history allocations to the socket, which is very wrong and I'll work on fixing in the coming days. Raised by ArnaldoMelo
36 - The service code in the REQUEST and RESPONSE packets is in network byte order and TcpDump is not using ntohl on it, below is the dump for a session where I used service=1=ntohl(16777216), one other idea is to look if the 4 bytes that compose the service are in the ASCII printable range and present it as "names" like suggested in the draft. Raised by ArnaldoMelo
37 - seqno 48 bit arithmetic when close to the seqno space limits. Raised by ArnaldoMelo
38 - we're not dropping packets when (CsCov? - 1) * 4 is greater than the length of the application data. Raised by ArnaldoMelo

Work now completed:
27 - NFS is broken in dccp-2.6.14-2.git. Notified Arnaldo. Fixed upstream by David Miller.
9 - Possibly bad checksums (either us or FreeBSD). Fixed by Nishida-san
3 - implement TIMEWAIT? state. Ian/Arnaldo. Status - Arnaldo is looking at generalising TCP TIMEWAIT?. - Done by Arnaldo, already merged upstream
11 - Kernel panics. Maybe due to retransmission after aborting of connection. Raised by Joacim. May be fixed or may be due to item 1 and/or 2. it was due to retransmission, the rto field was not being explicitely initialized and thus was being set to zero - Fixed by Arnaldo
8 - Update DCCP headers as per Joacim to fix sequence numbers. Arnaldo working on. Done by Arnaldo
23 - Fully generalise net/ipv4/tcp_diag.c into net/core/net_diag.c so that we have all of the iproute2/netlink functionality. Raised by Arnaldo. Status - done by Arnaldo, already in Dave's 2.6.14 git tree
17 - Can't modprobe -r dccp. Raised by IanMcDonald -> "Fixed" by Arnaldo, merged by Dave, look at the DCCP Kernel hacking menu for details
30 - Options and checksum are being displayed incorrectly in tcpdump. Need to work out if it is tcpdump or kernel code. Notified by IanMcDonald. Fixed - new patch posted 1 - SYN/RST storm - gets in a loop, sequence number on RST is rejected. IanMcDonald working on. Haven't seen recently and Arnaldo has worked on SYN stuff recently.
2 - Occasional lockup still although suspect caused by SYN/RST issue. IanMcDonald raised. Haven't seen recently.
16 - Option 192 for CCID3 is setting length field to zero incorrectly according to tcpdump. Raised by IanMcDonald. Status: Not seeing this from debug code in insert option so I wonder if packet handling is screwed up as also seeing things like option 25 which is not real. Fixed - was a bug in tcpdump and not using -s0
5 - loss is not causing CCID3 to slow down. IanMcDonald raised. Status: Tested with higher loss rate as not getting 3 packets needed to count as loss.
12 - Options are being sent as jiffies rather than 1 unit per 10 microseconds. Raised by Ian. Around line 1900 of ccid3.c. Working on Elapsed Time Option first but will affect Timestamp echo as well. Should SYNC/SYNCACK packets allow Elapsed Time Echo as only packets with acks are allowed this and these are special acks - yes says DCCP IETF mailing list. See item 19. Status - fixed
14 - Add CCID and options support for tcpdump. IanMcDonald raised. Status complete but can't add full CCID support easily as not tracked by packet
19 - To achieve item 12 I believe we need to refactor history and shift this from CCID3 to the main protocol. Raised by IanMcDonald. Currently being worked on by IanMcDonald and Arnaldo. 2 patches released so far - Arnaldo has reworked.
20 - We are sending far too many ACKs in CCID3 which generates unneeded network traffic. Raised by IanMcDonald
21 - Too much option processing is occuring in CCID3 code. Raised by IanMcDonald
28 - DCCP transmit performance is way down in dccp-2.6.14-2.git. Notified Arnaldo. Status - patch responsible identified by IanMcDonald and notification to list.
29 - Options for elapsed time, timestamp, timestamp echo etc are not implemented according to protocol. Notified by Nishida-san and IanMcDonald. Also elapsed time option has the wrong length. Status - elapsed time now has correct length
34 - Look at setting t_ipi to something else instead of TFRC_INITIAL_TIMEOUT. Raised by ArnaldoMelo. Status - done. 6 - get DCCP support into upstream tcpdump. IanMcDonald has submitted to tcpdump mailing list. Status - done. 13 - Look at packet buffering or API instead of just saying EAGAIN if can't transmit packet. Raised by Ian. Arnaldo commented that looking to revise dccp_sendmsg/recvmsg. Status: now it only returns -EAGAIN if O_NONBLOCK is being used or if the timeout expires
15 - Give feedback to userspace on rate, windowsize (presume CCID2 here), rate, loss rate through an API. Marie Camier raised, IanMcDonald also needs at some time. Status ArnaldoMelo has done some work here to be used by iproute2 - Now also available thru DCCP_SOCKOPT_CCID_RT?X_INFO getsockopt, investigation still needed on the need for a mmap interface
33 - When running ttcp you have to put in a -l500 in or else it comes back with errno 90 : IO Message too long. This is due to Path MTU not working correctly. - This is not really due to PMTU not working correctly, it already mostly works, needs just polishing on getting info from the CCIDs (CCMPS) and not just use a fixed overhead added to the MTU obtained from dst_mtu(), it is because ttcp by default uses 8192 sized packets, which is bigger than most PMTUs, so we have to use -l to change this default, chaning ttcp to use the TFRC default of 256 bytes by default if DCCP is being used (-c) seems to be a good idea.