Designing DCCP: Congestion Control Without Reliability

1. Designing DCCP: Congestion Control Without Reliability Eddie Kohler Mark Handley Sally Floyd UCLA University College London ICSI Center for Internet Research kohler@cs.ucla.edu M.Handley@cs.ucl.ac.uk floyd@icir.org Presented by: Sudipto Das Phd Student, CS@UCSB, sudipto@cs.ucsb.edu

2. Presentation Outline • Introduction • Description • Design Specifications • Conclusion

3. Introduction • Fast-growing Internet applications like streaming media and telephony prefer timeliness to reliability, making TCP a poor fit. • UDP, the natural alternative, lacks congestion control. • Especially a problem with long-lived flows and lots of traffic (streaming video, audio, internet telephony) • Goal is to ease the safe deployment of these applications - designing a congestion-controlled unreliable transport protocol. • The outcome, the Datagram Congestion Control Protocol or DCCP, adds to a UDP-like foundation the minimum mechanisms necessary to support congestion control.

4. Need for the New Protocol • Why not TCP • Applications share a preference for timeliness over reliability • TCP’s Reliable byte stream can introduce arbitrary delays • Applications do not want to implement TCP-friendly congestion control • Modular congestion control framework makes it easier to develop new applications.

5. Options available • Below UDP: too low • Above UDP: implement Congestion Control at application level • Lots of work, reinventing the wheel each time • Congestion Control is complex, might not be done correctly • New protocol more interoperable than a user-level library • Modify TCP, UDP, RTP, SCTP • Makes these protocols complex • Not general enough • Forces a reasonably fundamental change

6. Presentation Outline • Introduction • Description • Design Specifications • Conclusion

7. DescriptionGoals of Design • Minimalism (both in functionality and mechanism) • should not provide functionality that can successfully be layered above it by the application or an intermediate library • also helps achieve a secondary goal, namely minimal (or at least small) header size • Robustness • should be robust against data injection, connection closure, and denial-of-service attacks. • Led to the introduction of explicit connection setup and teardown

8. DescriptionGoals of Design • Framework for modern congestion control • should support all the features of modern TCP congestion control • provide a framework for implementing congestion control, not a single fixed algorithm • Self-sufficiency • implementations should be able to manage congestion control without application aid • Support timing-reliability tradeoff • should support not only naive applications, but also advanced applications that want fine-grained control over buffers and other tradeoffs between timing and reliability

9. DescriptionDeliberate Omissions • Flow Control • Omitted to extend support for timing-reliability tradeoffs • Selective Reliability • Retransmissions may sometimes be useful, but left out as they can be easily layered above DCCP • Streams • Multicast • DCCP mechanisms do not apply naturally to multicast

10. Presentation Outline • Introduction • Description • Design Specifications • Conclusion

11. Design Specifications • DCCP is unicast, connection-oriented protocol with bidirectional data flow • Connections start and end with three-way handshakes DCCP Packet exchange overview DCCP Packet Header

12. Design SpecificationsSequence Numbers • DCCP’s core connection management features all depend on sequence numbers • Included to detect loss without application support • Every packet occupies sequence space and uses mew sequence numbers • Ack no corresponds to the latest packet received, rather than the earliest not received

13. Design SpecificationsSynchronization • In case of network outages, DCCP supports explicit synchronizations • On receipt of unexpected seqno/ackno, endpoint send Sync pkt asking partner to validate seqno • Other endpoint replies with SynAck • Unique packets used to help mutually unsynchronized endpoints to synchronize Synchronization

14. Design SpecificationsConnection Management • Communication often asymmetric • DCCP logically divides each connection into half-connections • Consist of data packets from one endpoint plus corresponding acks from the other • Helps spend less resources in the inactive direction • Inbuilt mechanism for reliably negotiating the values of features • feature is simply a per endpoint property on whose value both endpoints agree

15. Design SpecificationsCongestion Control • Provides applications a choice of congestion control mechanisms • Choice made through Congestion Control IDs (CCIDs) • A connection’s CCIDs are negotiated at connection startup

16. Design SpecificationsCongestion Control • TCP-like congestion control (CCID 2) • Acks use the Ack Vector option (similar to TCP SACK) • Congestion control algorithm follows SACK TCP: maintains variable cwnd, ssthresh, and estimate of the number of data packets outstanding • Maintains a feature called Ack Ratio to detect and act on reverse path congestion • Used to control the rough ratio of data packets per acknowledgement.

17. Design SpecificationsCongestion Control • TFRC congestion control (CCID 3) • Uses a sending rate instead of congestion window • Receiver sends feedback to the sender reporting loss event rate • Sender uses information to determine sending rate • In case of no feedback for several RTTs, the sender halves its rate • As acknowledgments are limited, no need for ack congestion control

18. Design SpecificationsMisbehaving Receivers • DCCP Applications tolerate loss to some degree • Deliberate misbehavior like – acking data before it has arrived, must therefore be detected and dealt with • Sender provides an unpredictable nonce and receiver echoes them in the relevant acknowledgement • An endpoint detecting misbehaving partner should slow down its send rate in response

19. Design SpecificationsPartial Checksums & Non-congestion Loss • Several target applications like corrupted data to lost data (like audio and video applications) • DCCP allows checksums to cover less than the entire datagram (Checksum Coverage (CsCov)) • Restricted checksum coverage prompts underlying layers to forward corrupt datagrams – provided corruption is in the unprotected area • To differentiate Congestion loss from Corruption loss, DCCP allows receivers to report corruption separately

20. Presentation Outline • Introduction • Description • Design Specifications • Conclusion

21. Conclusion • DCCP – a relatively simple protocol that robustly manages congestion controlled connections without reliability. • Modular congestion control mechanism – makes it possible to adapt congestion control within a fixed protocol framework • Robustness against attack addressed in a more thorough way

22. References • DCCP Homepage • Internet Drafts, mailing lists, presentations • www.icir.org/kohler/dccp/ • DCCPimplementations • FreeBSD kernel-level implementation (Oct 2003) • University of Luleå, Sweden, www.dccp.org • Linux kernel-level implementation (2002) • http://www.ducksong.com:81/dccp/ • Linux user-level library (2002) • UC Berkeley, www.cs.berkeley.edu/~laik/projects/dccp/ • Congestion Manager • http://nms.lcs.mit.edu/projects/cm/

23. Questions? Thank You