Datagram Congestion Control Protocol (DCCP)

download Datagram Congestion Control Protocol (DCCP)

of 42

  • date post

    02-Feb-2016
  • Category

    Documents

  • view

    46
  • download

    0

Embed Size (px)

description

Datagram Congestion Control Protocol (DCCP). CISC 856 - TCP/IP and Upper Layer Protocols Presented by Ke Li ( kli@cis.udel.edu ) 2007/12/4 Thanks to Prof Amer, Kireeti Valicherla, and Xiaofeng Han. Overview. Motivation Connections Unreliable datagram transfer Modular congestion control - PowerPoint PPT Presentation

Transcript of Datagram Congestion Control Protocol (DCCP)

  • Datagram Congestion Control Protocol (DCCP)CISC 856 - TCP/IP and Upper Layer Protocols

    Presented byKe Li (kli@cis.udel.edu)2007/12/4

    Thanks to Prof Amer, Kireeti Valicherla, and Xiaofeng Han

  • *OverviewMotivation

    Connections

    Unreliable datagram transfer

    Modular congestion control

    Miscellaneous issues

  • *Adapted from Figure 2-11 TCP/IP Protocol Suite, Behrouz A. ForouzanDCCP: Which Layer?SCTPDCCP

  • *Streaming MediaSource: http://streaming.wisconsin.edu/Accessible_Tutorials/Tutorial1/p1-3.htmWhat streaming media needs?

    Timeliness of data

    What streaming media doesnt need?

    Retransmissions of lost/expired packets Annoying rebuffering HOL blocking

  • *D12D13A12A12D14 - D16

    Retransmit D13Data is not useful nowServerClientStreaming Media Over TCPD: data TCP-PDUA: ack TCP-PDU

  • *Streaming Media Over UDPNo congestion control in UDP flows

    Harmful to Internet healthServerClient

  • *Streaming Media with SCTP

    Multi-streams over a single associationUses TCP-like congestion control RetransmissionPartial Reliability: require at least 1 RTT

  • Other target applicationsInternet TelephonyConstant-packet-rate sources Change data rate by adjusting packet sizeExtremely sensitive to delayDemands a slower congestion responseInteractive gamesCan quickly make use of available bandwidthPrefers TCP-like sawtooth congestion response*

  • *Solution: DCCP

    provides unreliable flow of datagramsprovides congestion control usingAcknowledgmentSequence numberConnection orienteddoes not provideFull reliability: no-loss & no-error & in-order & no-duplicateflow controlstreamingDCCP = UDP + congestion controlor = TCP bytestream semantics full reliability

  • DCCP connectionsFull-duplex bi-directional connectionTwo logical half connectionsA-to-B half connection: Application data sent from A to BCorresponding acks from B to AIn practice overlapped: DataAckEach half connection can have independent features negotiated during connection initiation, e.g., different congestion control mechanism *DataAckDCCP ADCCP B

  • *DCCP ResponseDCCP RequestDCCP AckClientServerDCCP Connection InitiationCLOSEDLISTENREQUESTPARTOPENRESPONDCLOSEDOPEN

  • *DCCP Data Transfer PhaseDCCP DataDCCP AckDCCP DataAckDCCP DataOPENOPENDCCP ADCCP BPARTOPENClientServer

  • *DCCP Connection TerminationDCCP CloseDCCP ResetClientServerDCCP CloseReqWait 2 MSLDCCP CloseDCCP ResetClientServerWait 2 MSLTIMEWAITCLOSEDTIMEWAITCLOSEDCLOSEDCLOSEDCLOSEREQCLOSINGCLOSINGOPENOPENOPENOPEN

  • *DCCP Data Transfer Example 1. without loss

    Seq # on DCCP-PDU, not byteEach PDU carries a Seq #Seq # increases per PDUdetect loss congestion controlnetwork duplicate ignoredPure acks also consume Seq #possible to detect ack lossNo cum ack ack # is the Greatest Seq # Received (GSR) normallyData(seq #1)Data(seq # 2)Ack(seq # 11, ack # 2)Ack(seq # 10, ack #1)DCCP ADCCP B

  • *

    Maybe loss: no data retransmissionsSeparate options indicate PDU loss or ECN info: Ack Vector (SACK-like)Ack of Ack: clear receivers stateA PDU is ackable its header has been successfully processed (e.g., valid header checksum and seq #) Acked PDUs may be dropped -- no guarantee of data deliveryDue to receiver buffer overflow or corruption -- endpoint lossData dropped optionData(seq #1)Data(seq # 2)Ack(seq # 11, ack # 3)Ack(seq # 10, ack #1)DCCP Data Transfer Example 2. non-large burst of lossData(seq # 3)Data(seq # 4)Ack(seq # 12, ack # 4)DCCP ADCCP B

  • Sequence Validity CheckBoth endpoints keep expected seq#/ack# -- in syncTo detect seq# attacks, significant reordering, or one endpoint crashOut of sync after large burst of lossNo cum ack, use separate DCCP-Sync/SyncAck PDU to recoverSequence number variablesMaintained at each endpoint for each connectionGSR Greatest Seq# ReceivedGSS Greatest Seq# SentSequence validity windowsWindow width W: Seq Win featureExpected seq# [SWL, SWH], SWH=GSR+3W/4Expected ack# [AWL, AWH], AWH=GSSSeq#/ack# out of range seq invalid PDU, ignore and send Sync PDU*GSRW/43W/4WGSS

  • *DCCP Data Transfer Example 3. large burst of lossData(seq #20)Data(seq #31)Sync.ack# = out-of-sync seq# recvdDCCP ADCCP BData(seq #21)Data(seq #30)[13, 20]GSR Greatest Sequence number ReceivedGSS Greatest Sequence number SentWindow Size = 8Exp ack#GSS=20Exp seq#[14, 21]GSS=21[23, 30]GSS=30[24, 31]GSS=31[25, 32]GSS=32If Sync is ackable, SyncAck.ack# = Sync.seq#If valid ack#: update GSR, back to sync

  • *DCCP Data Transfer Example 4. slight reorderingData (seq #20)Data (seq #23)DCCP ADCCP BData (seq #21)Data (seq #22)[13, 20]GSR Greatest Sequence number ReceivedGSS Greatest Sequence number SentWindow Size = 8Exp ack#GSS=20Exp seq#[14, 21]GSS=21[15, 22]GSS=22[16, 23]GSS=23Data may be delivered out-of-order

  • *DCCP Data Transfer Example 5. medium reorderingDCCP ADCCP BData (seq #18)Data (seq #22)GSR Greatest Sequence number ReceivedGSS Greatest Sequence number SentWindow Size = 8Exp ack#Exp seq#[15, 22]GSS=22[16, 23]GSS=23If Sync is ackable, SyncAck.ack# = Sync.seq#If valid ack#: update GSR, back to sync

  • *DCCP Data Transfer Example 6. significant reordering (or blind attack)Data (seq #23)DCCP ADCCP BData (seq #10)Data (seq #22)GSR Greatest Sequence number ReceivedGSS Greatest Sequence number SentWindow Size = 8Exp ack#Exp seq#[15, 22]GSS=22[16, 23]GSS=23

  • *DCCP PDU TypesConnection InitializationData TransferConnection TerminationResynchronization

    DCCP-Request DCCP-Response DCCP-AckDCCP-Data DCCP-DataAck DCCP-CloseReq DCCP-Close DCCP-Reset DCCP-Sync, DCCP-SyncAck

  • *DCCP PDU FormatsGeneric header: 16 bytes (using 48bits seq#) or 12 bytes (using short 24 bits seq#)

    Additional fields: fixed length field, e.g. ack# (48b, 24b)

    Options: variable length field up to1008 bytes, e.g. Init Cookie, Ack Vector, Change, Confirm, Slow Receiver, Data Dropped

    Generic Header Additional Fields (depending on type) Options (optional )Application Data Area

  • *DCCP Generic Header081624X =1

    Source Port Destination Port Data Offset CCValCsCov (4bit)Checksum ResType (4bit)1ReservedSequence Number (high bits) Sequence Number (low bits)

  • *DCCP Generic Header: short081624X =0

    Source Port Destination Port Data Offset CCVal CsCov Checksum ResType0Sequence Number

  • *Acknowledgement Sub-HeaderX =1X =0 081624

    ReservedAcknowledgement Number (high bits) Acknowledgement Number (low bits)

    ReservedAcknowledgement Number(low bits)

  • *DCCP ChecksumHeader Checksum Coverage (CsCov): 4 bits CsCov = 0: covers the DCCP header (generic, additional), DCCP options, network-layer pseudoheader, and all application data in the packet (possibly some padding) CsCov = 1-15: covers the DCCP header, DCCP options, network-layer pseudoheader, and the initial (CsCov-1)*4 bytes of the packet's application data. Applications that can tolerate corruption can request header checksum only covers part or no app data at allCorrupted data could be delivered, impact on congestion controlImprove delivery rate and perceived performanceData checksum option provides strong CRC checksum for all application data0431

    CsCov Checksum

  • *Modular Congestion ControlEach congestion control mechanism supported by DCCP is assigned a 1-byte congestion control identifier, or CCID: a number from 0 to 255.

    CCID 0 and CCID 1 are reserved

    TCP-like congestion control CCID 2

    TCP friendly rate control (TFRC) CCID 3

    CCID 4-255 are reserved

    CCID is a feature to be negotiated and agreed on both endpoints

  • *CCID 2: TCP-like Congestion ControlCongestion control like TCP [RFC4341]Ack contains Seq# of all received packets within some windowCongestion event: packet loss, or ECN -> Halve congestion windowAbrupt rate changesReverse-path (Ack) congestion control: Ack Ratio R, integer, [2, cwnd/2]For each congestion window of data where at least one of the corresponding acks was lost or ECN-marked, R is doubled;For each cwnd/(R2-R) consecutive congestion window of data whose acks were not lost or ECN-marked, R is decreased by 1;The above formula comes from wanting to increase the number of acks per congestion window, namely cwnd/R, by 1 for every congestion-free window that passes.

  • *CCID 2: TCP-like Congestion Control [RFC4341]Applications using this:

    Respond quickly to changes in available bandwidth

    Must tolerate abrupt rate changes -- sawtoothOnline interactive games prefer this kind of congestion control

  • *Receiver-based feedback mechanismEquation-based congestion controlMinimizes abrupt changes in sending rate Maintains longer-term fairness with TCPStreaming Media prefer steadier and less bursty traffic as provided by TFRCCCID 3: TCP Friendly Rate Control [RFC 4342]

  • *CCID 3: TCP Friendly Rate ControlThe receiver measures the loss event rate and feeds this information back to the sender

    The sender uses these feedback messages to measure the round-trip time (RTT)

    The loss event rate and RTT are then fed into TFRC's throughput equation, giving the acceptable transmit rate

    The sender then adjusts its transmit rate to match the calculated rate

  • *Congestion related optionsSlow receiver optionReceiver sends this option to its sender to indicate it is having trouble keeping up with the senders data Sender shouldn't increase sending rate for about 1 RTT timeData dropped optionindicates that a packet was dropped due to corruption, receiver buffer overflow, application requirement, or other non congestion reasons.

  • *Feature Negotiation OptionsDCCP features on wh