Protocols Testing of DCCP at the Application Level
11
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester 1 Protocols Testing of DCCP at the Application Level Richard Hughes-Jones & Stephen Kershaw The University of Manchester www.hep.man.ac.uk/~rich/ then “Talks”
description
Protocols Testing of DCCP at the Application Level. Richard Hughes-Jones & Stephen Kershaw The University of Manchester www.hep.man.ac.uk/~rich/ then “Talks”. DCCP: Datagram Congestion Control Protocol. Unreliable No re-transmissions Has modular congestion control - PowerPoint PPT Presentation
Transcript of Protocols Testing of DCCP at the Application Level
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester1
Protocols
Testing of DCCP at the Application Level
Richard Hughes-Jones & Stephen Kershaw The University of Manchester
www.hep.man.ac.uk/~rich/ then “Talks”
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester2
DCCP: Datagram Congestion Control Protocol Unreliable
No re-transmissions
Has modular congestion control Can detect congestion and take avoiding action Different algorithms can be selected – ccid
TCP-likeTCP Friendly Rate ControlOthers possible
DCCP is like UDP with congestion control DCCP is like TCP without reliability Application uses
Multi-media – send new data instead of re-sending useless old data Applications that can choose data encoding & transmission rate VLBI – discussing a special ccid
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester3
DCCP: The Application View Stephen & Richard with help from Andrea Ported udpmon to dccpmon
Some system calls don’t work
getsockopt(*soc, SOL_DCCP, DCCP_SOCKOPT_CHANGE_L, &dccp_features, &len); Had problems with Fedora Core 6 using kernel 2.6.19-rc1
DCCP data packets never reached the receiving TSAP ! Verify with tcpdump Using development “patches” kernel 2.6.19-rc5-g73fd2531-dirty
dccpmon tests Plateau ~990 Mbit/s wire rate No packet Loss Receive system crashed!
Iperf tests 940Mbps, back-to-back
Need more instrumentation in DCCP Eg a line in /proc/sys/snmp
zeus15-atb79_29Sep06
0100200300400500600700800900
1000
0 10 20 30 40Spacing between frames us
Recv W
ire r
ate
Mbit/s
800 bytes
1000 bytes
1200 bytes
1400 bytes
1424 bytes
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester4
DCCP: “Latest” Kernel Kernel 2.6.19_pktd-plus - ~2 weeks old then dccpmon tests
Receive system crashed even faster ! Just 1 or 2 1000,000 packet tests
Iperf tests OK short runs 940Mbps, back-to-back Hangs, but runs for longer !
Contact with linux-foundation via PFLDnet2007
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester5
Porting dccpmon to 2.6.20 DCCP #defines not in the userland include files
Use own include files Values have changed since 2.6.19
Some API calls changed as well
Still no SNMP information
Process cannot be removed – reboot needed
dccpmon being tested
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester6
Iperf with CCID2 Kernel 2.6.20-web100_pktd-plus (64 bit) Intel e1000 1 Gigabit NIC Back-2-back MTU 1500 bytes
Constant throughput of 940 Mbit/s Moved 788 GBytes 2 Hrs. CRASH FREE
But had increased kernel parameter min_free_kbytes to 65535 in receiving host (default = 5741)
Min_free_kbytes is the amount of memory available for atomic allocations by the network driver at interrupt level .
kswapd daemon swaps kernel data around to keep this amount of free memory available.
CCID2 iperf
0
100
200
300
400
500
600
700
800
900
1000
0 2000 4000 6000 8000
Time s
Th
rou
gh
pu
t M
bit
/s
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester7
Iperf with CCID3 Kernel 2.6.20-web100_pktd-plus (64 bit) Intel e1000 1 Gigabit NIC Back-2-back MTU 1500 bytes
min_free_kbytes = 65535 inreceiving host
300 kbit/s for 40 min ! Then constant throughput of 940 Mbit/s
CCID3 iperf
0
100
200
300
400
500
600
700
800
900
1000
0 2000 4000 6000 8000
Time s
Th
rou
gh
pu
t M
bit
/s
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
0 200 400 600 800 1000
Time s
Th
rou
gh
pu
t M
bit
/s
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester8
Variation with min_free_kbytes Kernel 2.6.20-web100_pktd-plus (64 bit)
min_free_kbytes = 5471 [default] in receiving host Iperf can run for about 5mins usually crashes in a few sec
min_free_kbytes = 65535 in receiving host Iperf can run for about 2 Hrs
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester9
DCCP: CCID=SafeUDP [20]
VLBI has a clear requirement to move CBR data UDP seems ideal
Other applications NEED this form of delivery RTP / RTSP
Lots of streaming applications available now
Discussed at recent meetings EXPReS & EVN-NREN meeting in Zaandan, NL PFLDnet 2007 / IRTF workshop in Marina Del Rey, US
Concern expressed about UDP overloading the Academic Network Input from Kees Neggers, SURFnet; Glen Turner, AARNET; Aaron
Falk, IRTF Chair
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester10
DCCP: CCID=SafeUDP [2]
Propose a CCID that is “UDP like” but with Network protection
Use the DCCP ACK mechanism to detect congestion Note: detection of congestion alone is not sufficient
Evaluate congestion: Ensure congestion is in the network not the end hosts. Test if the congestion is transient.
Inform the application RTP / RTSP of the congestion Use of new return codes to existing API sendto(), recvfrom(), etc
If, after some time interval, the application takes no actiondrop the input from the application. Use of new return code to indicate this.
Working with partners with the aim of a draft RFC
ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester11
Any Questions?
