Master

1
Masters Project Presentation

• Datagram Congestion Control Protocol (DCCP) using
  TCP like congestion control
• By Deval Mehta
• Instructor Dr. Chang -E- Wang

2
Why DCCP?

• A steady growth of applications that generate
  long-lived flows of UDP datagrams
• Internet telephony, streaming video and on-line
  games
• TCP can introduce arbitrary delay because of its
  reliability and in-order delivery requirements
• Thus, these applications use non-congestion-contro
  lled UDP instead
• This lack of congestion control poses a threat to
  the network
• New transport protocol that combines unreliable
  datagram delivery with built-in congestion
  control is needed

3
Features

• An unreliable flow of datagrams, with
  acknowledgements.
• A reliable handshake for connection setup and
  teardown.
• Reliable negotiation of options, including
  negotiation of a suitable congestion control
  mechanism.
• Mechanisms allowing a server to avoid holding any
  state for unacknowledged connection attempts or
  already-finished connections. (Low Overhead)
• Optional mechanisms to indicate sent/received
  packets and whether those packets are ECN
  (Explicit Congestion Notification) marked,
  corrupted or dropped in the receive buffer.

4
Difference b/w TCP like and TFRC type congestion
control

• Halves the congestion window in response to a
  packet drop or mark, as in TCP.
• A form of equation-based congestion control,
  minimizes abrupt changes in the sending rate
  while maintaining longer-term fairness with TCP.

5
Anatomy of a DCCP Connection

• Each DCCP connection runs between two endpoints,
  DCCP A and DCCP B.
• Data may pass over the connection in either or
  both directions.
• The DCCP connection between DCCP A and DCCP B
  consists of four sets of packets, as follows
• Data packets from DCCP A to DCCP B.
• Acknowledgements from DCCP B to DCCP A.
• Data packets from DCCP B to DCCP A.
• Acknowledgements from DCCP A to DCCP B.

6
Packet format

• Generic packet header

- CCval sending CCID information - Data offset
padding - NDP Number of Non-Data Packets -
CSLen checksum length - Checksum
7
Packet types

• 16 types are possible (4bit)
• Currently 9 types are used

1. DCCP-Request
2. DCCP-Response
3. DCCP-Data
4. DCCP-Ack
5. DCCP-DataAck piggybacking
6. DCCP-CloseReq
7. DCCP-Close
8. DCCP-Reset
9. DCCP-move for mobility, multihoming

8
DCCP Connection ..

• Client Server

DCCP- Request with ports and features negotiation
including CCID
DCCP- Response with agreement of feature and
options
DCCP-Ack for DCCP-Response OR DCCP-DataAck to
piggyback the Data
DCCP-CloseReq by server requesting close
DCCP-Close by client Acknowledging the close
DCCP-Reset with Reason field set to Closed to
clear the state..
9
Congestion Control.

• Server continues sending DCCP-Data packets as
  controlled by the congestion window.
• Server examines the Ack vector to learn about
  marked or dropped data packets.
• Adjusts its congestion window accordingly
• Dose not send retransmit dropped packets.

10
Connection breakdown

• Two half-connections

Data from A to B plus acks from B to A Data from
B to A plus acks from A to B Ack piggybacking a
single packet relevant to both half-connections
11
Acknowledgements

• DataAck acks the largest received
• sequence number, Not the most recent sequence
  number
• Ack Vector option Provides detailed loss
  information Which packets were received? ECN
  marked?

12
CCID2 TCP like

• DCCPs TCP-like congestion control framework
  differs from that of TCP
• Senders congestion window is still used
• But, it can not use a cumulative acknowledgement
  field to control this
• If packets are lost, the sender halves its
  sending rate appropriately
• DCCP can detect reverse-path congestion using
  per-packet sequence numbers, and respond to it
  appropriate

13
CCID 2 congestion control overview Variables

• cwnd congestion window
• Maximum number of data packets allowed in the
  network
• ssthresh slow-start threshold
• Controls adjustments to cwnd
• pipe
• Sender's estimate of number of outstanding data
  packets
• MAY send data packets if pipe lt cwnd
• Increase pipe by 1 on every newly sent data
  packet

14
Pipe Reduction

• HC-Sender reduces pipe as it infers data packets
  have left the network
• Reduce pipe by 1 for each data packet newly acked
• Reduce pipe by 1 for each data packet inferred as
  lost
• Retransmit" timeouts, in case a whole window
  lost
• Estimate RTT as TCP
• Set RTO as TCP (but minimum RTO not necessary)
• When RTO occurs, set pipe to 0

15
cwnd manipulation

• Congestion events halve cwnd, set ssthresh new
  cwnd
• One or more packets lost or marked from a window
  of data Marked Code 1 lost inferred through
  Ack Vector
• Congestion window increases
• When cwnd lt ssthresh, increase cwnd by 1 for
  every newly acknowledged data packet, up to some
  max
• Otherwise, increase by 1 for every window of data
  acknowledged without lost or marked packets

16
Sending acknowledgements

• Send about one ack per R data packets received
• R is the Ack Ratio
• Reasons to send more acks
• Delayed ack timer as TCP
• Ack piggybacking doesn't count towards R

17
Congestion control on acknowledgements

• For each cwnd of data with at least one lost or
  marked ack, double R (Ack Ratio)
• For each (cwnd/(R2 - R)), cwnds of data with no
  lost or marked acks, decrease R by one

18
Example of DCCP connection

• A -gt B 0 Request, Ask(CCID 2)
• B -gt A 100 Response0, Answer(CCID 2),
  Ask(CCID 0)
• A -gt B 1 DataAck100, Answer(CCID 0)
• B -gt A 101 Data, media data
• B -gt A 102 Data, media data
• A -gt B 2 DataAck102, Ack Vector(v102 v101)

19
Example of DCCP connection

• B -gt A 103 Data, media data
• B -gt A 104 Data, media data LOST
• B -gt A 105 Data, media data
• B -gt A 106 DataAck2, media data
• A -gt B 3 DataAck103, Ack Vector(v103 v102
  v101)
• A -gtB 4 DataAck106, Ack Vector(v106 v105 X104
  v103)

20
Example of DCCP connection

• B à A 107 DataAck4, media data
• B à A 108 Data, media data
• A à B 5 DataAck108, Ack Vector(v108 v107)
• . . .
• B à A 200 CloseReq80
• A à B 81 Close200
• B à A 201 Reset81

21
Checksums

• Based on UDP-lite
• Purposes
• To support applications that can deal with
  corrupt data
• Avoid congestion response to corruption
• Suggestion
• Complete checksum CSLen 1, DCCP packets IP
  header
• Partial checksum CSLen0, DCCP/IP header, but
  not payload

22
Summary

• DCCP provides solution to unreliable dataflow
  without congestion control..
• New datagram standards for applications which
  require in time delivery of data packets with
  congestion control
• Provides option to congestion control