Datagram Congestion Control Protocol (DCCP)

111Advance Computer NetworkingVinh Do

Datagram Congestion Control Protocol (DCCP)

Vinh Do

CS529– Advance Computer Network

California State University, Northridge

May 16 2005


Introduction

TCP- Transport Control Protocol

• Connection Oriented-provide reliable data transfer, flow control, congestion control

• Guarantee data delivery

• Delay tolerance

• Files transfer, Web browsing, email apps

UDP- User Datagram Protocol

• Connectionless

• Guarantees nothing

• No Congestion Control

• DNS, SNMP, streaming media, telephony, on-line games


Introduction (Cont.)

Increasing long-lived applications using UDP

• Streaming media-audio/video, Internet telephone, on-line

games

• Prefer timeliness over reliability-loss tolerance

• TCP is not suitable- retransmission delay

Increase of long-lived non-congestion control traffic degrades the network’s performance; can cause collapse of the network


Solutions

Congestion Control at Application level

• Reinventing the wheel each time

• Difficult to implement

• Issue of Interoperability

SCTP-Stream Control Transmission Protocol

• unnecessary per-packet overhead

DCCP: Congestion Control for UDP

• Simple packet header

• TCP-like (CCID2): high throughput, abrupt rate change (games)

• TFRC (CCID3): steadier rate, lower throughput (telephony)


TCP Congestion Control

TCP senders change the sending rate:

Window = min{ receiver Window, Congestion Window}

Receiver Transmitter(“cwnd”)

Sender perceives congestion when:

• loss event = timeout or 3 duplicate acks

TCP sender reduces rate after loss event

Three mechanisms:

• additive increase/multiplicative decrease (AIMD), slow start,

reaction to timeout events

rate = cwnd

RTT Bytes/sec


TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

multiplicative decrease: cut cwnd in half after loss event

additive increase: increase cwnd by 1 MSS every RTT in the absence of loss events: probing

Long-lived TCP connection


TCP Slow Start

• When connection begins (cwnd = 1 MSS), increase rate exponentially until first loss event:– double cwnd every RTT– done by incrementing cwnd for

every ACK received

• Initial rate is slow but ramps up exponentially fast

Host A

one segment

RTT

Host B

time

two segments

four segments


Reaction to timeout events

After 3 duplicate acks

• cwnd *= .5

• window then grows linearly

After timeout event

• cwnd = 1MSS

• window then grows exponentially to a threshold then grows linearly


Reaction to timeout events (cont.)

• When cwnd gets to 1/2 of its value before timeout the exponential increase switch to linear (congestion avoidance).

• Variable Threshold (initially set to a large value)

• At loss event, Threshold is set to 1/2 of cwnd just before loss event


TCP sender congestion control

Event State TCP Sender Action Commentary

ACK receipt for previously unacked data

Slow Start (SS)

cwnd= cwnd + MSS, If (cwnd > Threshold) set state to “Congestion Avoidance”

Resulting in a doubling of cwnd every RTT

ACK receipt for previously unacked data

CongestionAvoidance (CA)

cwnd = cwnd+MSS * (MSS/cwnd)

Additive increase, resulting in increase of cwnd by 1 MSS every RTT

Loss event detected by triple duplicate ACK

SS or CA Threshold = cwnd/2, cwnd = Threshold,Set state to “Congestion Avoidance”

Fast recovery, implementing multiplicative decrease. cwnd will not drop below 1 MSS.

Timeout SS or CA Threshold = cwnd/2, cwnd = 1 MSS,Set state to “Slow Start”

Enter slow start

Duplicate ACK SS or CA Increment duplicate ACK count for segment being acked

cwnd and Threshold not changed


DCCP: Datagram Congestion Control Protocol

Design for time-sensitive applications

Sender controls transmission rate

Different mechanisms for different type of traffic- currently TCP-like and TFRC

Support for ECN, ECN none, partial check sum,…

Features negotiations

Two half-connections


DCCP Packet types

9 packet types defined

• DCCP-Request client server: open connection

• DCCP-Response server client: response

• DCCP-Data transmit data

• DCCP-Ack transmit ack info

• DCCP-DataAck DCCP-Data + DCCP-Ack

• DCCP-CloseReq server client: close connection

• DCCP-Close close connection

• DCCP-Reset destroy connection

• DCCP-Move move IP address/port


Connection States

8 states

•CLOSED no connection

•LISTEN server in passive listening state

•REQUEST client beginning 3-way handshake

•RESPONSE server responding to request

•OPEN data transfer (connection established)

•CLOSEREQ server asking client to close

•CLOSING client waiting for final reset

•TIMEWAIT2MSL(max segment lifetime) wait(at receiver of reset)


Two half-connections

A Half-connection is data flowing in one direction plus the corresponding acks

DCCP contains 2 half-connections

•A B data plus B A acks

•B A data plus A B acks

•Can also piggyback acks on data (DCCP-DataAck)

Each Half-connection may use different Congestion mechanism

HC-Sender is the endpoint sending data, HC-Receiver is the endpoint sending acks


Packet Formats

+----------------------------------------------------------+ | Generic Header | +----------------------------------------------------------+ | Additional Fields (depending on type) | +----------------------------------------------------------+ | Options (optional) | +==================================+ | Application Data Area | +----------------------------------------------------------+


Options

Option Length

Type

0 1 Padding2 1 Slow Receiver32 3-4 Ignore33 variable Change34 variable Prefer35 variable Confirm36 variable Init Cookie37 variable Ack Vector [Nonce 0]38 variable Ack Vector [Nonce 1]39 variable Data Dropped40 6 Timestamp41 6 – 10 Timestamp Echo42 variable Identification44 variable Challenge45 4 Payload Checksum46 4-6 Elapsed Time

128-255 variable CCID-specific options

Meaning


Connection Control IDs (CCIDs)

Each congestion control mechanism supported by DCCP is assigned a CCID; a number from 0-255

Each half-connection has a CCID feature

CCID Meaning

0 Reserved 1 Unspecified Sender-Based Congestion Control 2 TCP-like Congestion Control 3 TFRC Congestion Control


Features

Number Meaning

1 Congestion Control (CC) 2 ECN Capable 3 Ack Ratio 4 User Ack Vector 5 Mobility Capable 6 Loss Window 7 Connection nonce 8 Identification Regime

128-255 CCID-Specific Features

seThe first data byte of every

Change, Confirm option is a feature number

Negotiable

YYNYYNN Y

?


Feature Negotiation

At the beginning of connection the endpoints must agree on a set of parameters

• The CCIDs, CCID-specific settings, Loss Window, Connection Nonces, …

Four DCCP options: Change L, Confirm L, Change R, Confirm R are used to negotiate feature values


Feature Negotiation Examples

Example 1

DCCP A DCCP B

Change R(CCID, 2 3 1)

Confirm L(CCID,3, 3 2 1)

• Client A: “2 3 1” is client’s preference list

• Server B: 3 is the negotiate val; 3 2 1” is server preference list

• Agree that CCID/Server = 3

Example 2

DCCP A DCCP B

Change L(Arc Ratio, 3)

Confirm R(Arc Ratio, 3)

• Agree that Ack Ratio/Server = 3


Connection example


Connection example (Cont.)


Sequence Numbers

Per-packet sequence number

Increase by 1 on every packet sent including pure acks

DCCP checks packet’s Sequence and Acknowledgement Numbers for validity

• Defense against delivery of old segments

• Defense against half-open connections

• Defense against attack

Sequence and Acknowledgement Window

• Used for validity check


Sequence and Acknowledgement Window

HC-Sender decides on a Ws (Sequence Window width) for sequence numbers

HC-Receiver decides on a WA (Ack Window width) for ack numbers


Acknowledgements

Ack number is GSR (Greatest Sequence Number)

• Different from TCP – cumulative ack meaningless in an reliable protocol

Different CCIDs requires differents acknowledgement formats

Generic ack option: Ack Vector-used to determine exactly which packets have been received

TFRC ack options: Receive rate, Loss Event Rate, Loss Intervals

Acknowledgements must be reliable- retransmit until received


Acks of Acks

Acknowledgement information represents state- Ack vector

Receiver must free the state once the sender receive ack

Sender must send ack to receiver’s ack

State Meaning

0 Received

1 Received ECN marked

2 Reserved

3 Not Yet Received

DCCP Ack vector


Acknowledgements Congestion Control

Per-packet seq # allow acknowledgement to be congestion controlled

CCID determines when HC-receiver can send acks

Ack ratio feature

• Send one ack per R packets

• R default is 2

• Higher ack ratios correspond to lower DCCP-Ack rates

• Sender raises Ack-Ratio when the reverse path is congested and lowers Ack-Ratio when it is not


Mobility

Endpoint moves, send DCCP-Move to other from new address

• DCCP-Move contains old address so flow can be identified

• Stationary endpoint acknowledges with a DCCP-[Data]Ack

• Attacker can guess seq number and might move a DCCP-connection to its own address

DCCP-Move security

• Need security mechanism (Identification)- DCCP-Move packets carry valid id options (MD5 hash of two shared secret)

• Ignore invalid sequence numbers, identification

• Do not send ack or reset – lead to leak info

• May ignore all moves for sometimes after receiving invalid move to prevent DoS attacks


CCID2-TCP-like Congestion Control

TCP-like congestion control

• Utilize available bandwidth

• Abrupt AIMD rate changes (like TCP)

Congestion control algorithm based on SACK TCP

• Three variables: cwnd, ssthresh, pipe

• RTT estimation

• Acknowledgement use Ack-Vector

Acknowledge Congestion Control

•Ack-Ratio manipulation


CCID2’s variables

cwnd (congestion window)- Maximum number of data packets allowed in a network

ssthresh (slow-start threshold)- control adjustment to cwnd

Pipe

• Sender’s estimate of number of outstanding data packets in the network

• May send data if pipe < cwnd

• Increase pipe by 1 on every newly sent data packet


Pipe reduction

HC-Sender reduces pipe as it infers data packets have left the network

Reduce pipe by 1 for every packet newly acked as Ack-vector state 0 or state 1

Reduce pipe by 1 for each packet infers as lost due to the DCCP equivalent of TCP’s “duplicate acks”

• Packet P infers lost when at least NUMDUPACK (= 3) packets has been acked as Ack-vector state 0 or state 1

• NUMDUPACK packets need not be data packet specifically, can also be Ack packets or other none data packets

Transmit timeout

• Handle like TCP’s retransmit timeout

• Use TCP’s Estimate RTT

• When timeout, set pipe to 0


CWND manipulation

Congestion events half cwnd, set ssthresh = new cwnd

• One or more packets lost or marked from a window of data

Timeout events set ssthresh = ½ cwnd then set cwnd = 1

Congestion window increases

• when cwnd < ssthresh increases cwnd by 1 for every newly acked data packet

• Else, increase by 1 for every window of data acked without lost or marked packets


Acknowledgements

Sender uses Ack-Ratio feature to influence the sending rate at which DCCP is generated

Receiver send one ack per R data packets received

Enable reverse path congestion control

For each cwnd of data with at least one lost or marked ack, double R (Ack Ratio)

For each cwnd/(R^2 – R) consecutive cwnds of data with no loss or marked DCCP-Ack packets, R is decrease by 1


Determining Quiescence

Definition: State at which one end point stops sending data packets for some amount of time (ie 2RTTs)

HC-Receiver detects that HC-Sender is quiescence when max(0.2sec, 2RTT) have passed without receiving data

When other CCID is quiescence, HC-Sender sends about one ack per cwnd


Explicit Congestion Notification

The sender use the ECN nonce for data packets and the receiver will echo those nonce in its Ack vectors

For unmarked data packets,The receiver computes the ECN Nonce Echo and returns it as part of its Ack vectors

The Sender should check the ECN nonce Echoes against unexpected values

• protecting against the accidental or malicious concealment of marked packets


TFRC-CCID3

TCP-friendly, but avoids abrupt rate changes

TFRC congestion control algorithms

• Equation-based congestion control

• Receiver calculates loss event rate, sender adjusts accordingly

• Acknowledgements need not use Ack Vector


Overview of CCID3

HC-Sender sends data packets at most at the rate specified by the throughput equation

• Rate-based congestion control

• Data packets include Window Counter (helps receiver distinguish packets sent in different RTTs); sent in Ccval in the header

HC-Sender updates rate based on the loss event rate specified on ack packets from the receiver or it can calculate that rate itself from Ack Vector or Loss Interval


Loss events

A Loss Interval:

• Begins with a lost or marked packet

• Continues for one RTT’s worth of packets (lost, marked, or not)

• Concludes with an arbitrary-length tail of none-lost, non-marked packets

The Loss Event Rate: The inverse of a weighted average of the last 8 Loss Interval lengths


Acknowledgements

Elapsed Time and/or Timestamp Echo options

• Aid RTT estimation

• Feedback packets sent once per RTT, elapsed time may be large

Receive Rate option- Determine how fast the receiver has been receiving data

One or more options describing the loss event rate

• Loss Event Rate: list rate explicitly

• Loss Interval: the beginning and end of each loss interval

• Ack Vector: Sender can calculate loss intervals


Loss Event Rate option

Used by Receiver for calculation of loss event rate

11000000 00000110 Loss Event Rate

Type=192 Len=6


Loss Intervals option

Receiver reports its observed loss intervals using loss interval options

Can report Up to 28 loss intervals

• Currently TRRC lists the last 9 loss interval lengths

Sender can calculate Loss Rate

Sender can verify ECN Nonce Echo

11000001 Length Loss Interval More Loss Interval …

Type=193 9 bytes


Differences from TCP

Packet Stream, not byte stream protocol

Unreliability-never retransmit a datagram

Options are retransmitted to make feature and acknowledgement reliable

Packet sequence numbers

Feature negotiation

Choice of congestion control

No receive window-not a flow control protocol


Differences from TCP (cont.)

Different acknowledgement format, The CCID determine how much ack info is to be transmitted

• CCID2: one ack per 2 packets, each ack must declare exactly which packets it receives (Ack vector option)

• CCID3: one ack per RTT and acks must declare at minimum just the length of recent loss interval

Distinguish different kinds of loss: Data drop option declare a data packet is dropped because of received buffer flow or corruption

Datagram Congestion Control Protocol (DCCP)

Documents

Transcript of Datagram Congestion Control Protocol (DCCP)