Re: DCCP Conformance Test Suite

[Wei Yongjun <yjwei@cn.fujitsu.com>]

Gerrit Renker wrote:
> | Download:
> | It is available at:
> | http://dccpct.sourceforge.net/download.html
> | 
> | - v6eval with DCCP support:
> | http://dccpct.sourceforge.net/v6eval-3.0.14-linux-dccp.tar.gz
> | 
> | - Test Suite:
> | http://dccpct.sourceforge.net/dccp-1.0.0.tar.gz
> | 
> | Usage:
> | http://dccpct.sourceforge.net/usage.html
> | 
> | Test Report under IPv4:
> | http://dccpct.sourceforge.net/log/ipv4/index.html
> | 
> This is a great piece of work and thank you for making it publicly available.
> Such a tool has long been missing and I hope that the word will soon spread and 
> that there will be ongoing test effort.
>
> Your work has been valuable help in isolating several hard-to-find bugs
> and I very much hope that you will continue to contribute.
>
> Regarding future tests, several things come to mind, where fixing
> existing bugs takes precedence.
> 	  
> Here are a few suggestions. I am not sure whether they fit the frame of the
> TAHI suite. The underlying idea is to use a traffic monitor and controlled
> packet drop to check the behaviour of the stack under loss.
>
> The first use is to test stability of protocol signalling. Maybe you
> remember the feature-negotiation bug which only appeared when the Ack
> completing the setup handshake was dropped. Leandro observed this bug
> when packets were (presumably) dropped due to forking many DCCP
> connections in parallel. To trigger this bug between two machines
> required a modification of the kernel sources - which was
> work-intensive.
>   

Used TAHI's test frame, we can send any packet we want. Say simplely, 
the endpoint under test is an DCCP application wich used the kernel's 
implementation, but the endpoint used for test does not uesd any DCCP 
implementation, it do all of the work by send packet I defined in the 
test case. So this kind test case is easy to do.

> The second application is to validate the behaviour of Ack Vectors. This
> is however a bit complicated to do: the traffic monitor needs to keep
> track of which packets were lost, and check if these sequence numbers
> show up in the run-length encoded Ack Vector going back in the reverse
> direction. If it would be possible to automate such tests, that would be
> awesome, since manually verifying Ack Vectors is a very tedious task to
> do. The Ack Vector code needs more work anyway, since on 802.11g I found
> that they grow up to half a kilobyte in length, which is too much.
>   

Maybe TAHI is available, I'll have a try.
> Last, there is ongoing work to add ECN support. For ECN it would be
> helpful to look at the behaviour, since ECN router support seems quite
> young

Do you mean send packet with ECN in the ip header? I'll have a look to 
the ECN RFC, and check if it can.

Thanks.

Wei Yongjun