Download - Designing DCCP: Congestion Control Without Reliability

A Pragmatic Approach towards the Improvement of Performance of Ad Hoc Routing ProtocolsDesigning DCCP: Congestion Control Without Reliability

CS595F (Fall 2006): Systems and Networking Seminar

Designing DCCP: Congestion Control Designing DCCP: Congestion Control Without ReliabilityWithout Reliability

Presented by:

Sudipto DasSudipto Das

Phd Student, CS@UCSB, [email protected]

Eddie Kohler Mark Handley Sally Floyd UCLA University College London ICSI Center for Internet [email protected] [email protected] [email protected]

Jadavpur UniversityDesigning DCCP: Congestion Control Without Reliability


Presentation OutlinePresentation Outline

IntroductionIntroduction

Description Design Specifications Conclusion



IntroductionIntroduction 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.



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.

Need for the New ProtocolNeed for the New Protocol



Options availableOptions 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



Presentation OutlinePresentation Outline Introduction

DescriptionDescription

Design Specifications Conclusion



DescriptionDescriptionGoals of DesignGoals 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



DescriptionDescriptionGoals of DesignGoals 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



DescriptionDescriptionDeliberate OmissionsDeliberate 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



Presentation OutlinePresentation Outline Introduction Description

Design SpecificationsDesign Specifications

Conclusion



Design SpecificationsDesign 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



Design SpecificationsDesign SpecificationsSequence NumbersSequence 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



Design SpecificationsDesign SpecificationsSynchronizationSynchronization

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



Design SpecificationsDesign SpecificationsConnection ManagementConnection 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



Design SpecificationsDesign SpecificationsCongestion ControlCongestion 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




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.




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



Design SpecificationsDesign SpecificationsMisbehaving ReceiversMisbehaving 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



Design SpecificationsDesign SpecificationsPartial Checksums & Non-congestion LossPartial 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



Presentation OutlinePresentation Outline

Introduction Description Design Specifications

ConclusionConclusion



ConclusionConclusion 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



ReferencesReferences DCCP Homepage

Internet Drafts, mailing lists, presentations www.icir.org/kohler/dccp/

DCCP implementations 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/

http://www.icir.org/kohler/dccp/

http://www.icir.org/kohler/dccp/

http://www.dccp.org/

http://www.cs.berkeley.edu/~laik/projects/dccp/




A Pragmatic Approach towards the Improvement of Performance of Ad Hoc Routing ProtocolsDesigning DCCP: Congestion Control Without Reliability


Questions?Questions?

Thank YouThank You