1 / 11

Protocols Testing of DCCP at the Application Level

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

oswald
Download Presentation

Protocols Testing of DCCP at the Application Level

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ProtocolsTesting of DCCP at the Application Level Richard Hughes-Jones & Stephen Kershaw The University of Manchesterwww.hep.man.ac.uk/~rich/ then “Talks” ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester

  2. 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-like • TCP Friendly Rate Control • Others 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 Manchester

  3. 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 ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester

  4. 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 Manchester

  5. 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 Manchester

  6. 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. ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester

  7. 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 ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester

  8. 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 Manchester

  9. 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 Manchester

  10. 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 Manchester

  11. Any Questions? ESLEA Closing Conference, Edinburgh, March 2007, R. Hughes-Jones Manchester

More Related