Differences between current version and predecessor to the previous major change of DCCPToDo.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 32 | Last edited on Wednesday, October 26, 2005 11:03:26 am | by IanMcDonald | |
| Older page: | version 31 | Last edited on Monday, October 3, 2005 11:51:26 am | by IanMcDonald | Revert |
@@ -1,51 +1 @@
-Todo list for
[DCCP
]
-
-WikiGnome~s - 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 [CCID]2 and other experimental [CCID]s.%%%
-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 <tt>ip_conntrack_proto_dccp.c</tt> (or even better: <tt>nf_conntrack_proto_dccp.c</tt>) 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 <tt>dccp-2.6.14-2.git</tt>. 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 <tt>net/ipv4/tcp_diag.c</tt> into <tt>net/core/net_diag.c</tt> so that we have all of the [iproute2|ip(8)]/[netlink|LinuxNetlinkSockets] functionality. Raised by Arnaldo. Status - done by Arnaldo, already in Dave's 2.6.14 git tree%%%
-17 - Can't <tt>modprobe -r dccp</tt>. 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 [CCID]3 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 [CCID]3 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 <tt>ccid3.c</tt>. 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 [CCID]3 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 [ACK]s in [CCID]3 which generates unneeded network traffic. Raised by IanMcDonald%%%
-21 - Too much option processing is occuring in [CCID]3 code. Raised by IanMcDonald%%%
-28 - [DCCP] transmit performance is way down in <tt>dccp-2.6.14-2.git</tt>. 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 [CCID]2
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|EMSGSIZE]. 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
.%%%
+Describe
[DCCPToDo
] here.
