DCCP: Transport Protocol with Congestion Control and Unreliability

More documents

Recommendations

Info

Transport Protocol with Congestion Control and Unreliability(seqno=2), and the server respondswith packet(seqno=5 and ackno=2).Consequently, the client sendspacket(seqno=3 and ackno=5).During the transfer process, DCCPendpoints might use DCCP-Sync andDCCP-SyncAck packets for synchronization.In Figure 3, suppose that the clientsends packets(seqno=10~101),and only packet(seqno=10) andpacket(seqno=101) arrive at theserver, while the remaining packetsare lost. The server receivespacket(seqno=101), but this sequencenumber isn’t within seqno’sexpected range. To synchronize thesequence numbers in the client, theserver immediately sends a DCCP-Sync packet and acknowledges receivingthe packet with ackno=101.When the client receives this DCCP-Sync packet, it immediately respondswith a DCCP-SyncAck packet. Uponreceiving this packet, the serverchanges the expected range of seqnoto synchronize both sides.In contrast to TCP acknowledgments,DCCP acknowledgments havetwo distinguishing characteristics:they’re restricted by congestion control,and the sender must report itsacknowledgment reception to thereceiver in a timely manner. Eachacknowledgment has an ack vectoroption that the receiver uses to reportits packet reception to the sender.The vector comprises a series of8-bit blocks, including state (2 bits)and run length (6 bits). The vectorhas three defined states: received (0),received but with an explicit congestionnotification (ECN) mark (1), andnot yet received (3). Run length representshow many consecutive packetsare in the given state.As the receiver gets more packets,it reports more receiving conditionsto the sender, thus causing the ackvector’s size to gradually increase.So, the sender must occasionallyreply to the receiver through theacks-of-acks, notifying the receiverabout which acknowledgments theClientDCCP-Data(seq1)DCCP-Data(seq2)DCCP-Ack(seq5, ack2)DCCP-DataAck(seq3, ack5)DCCP-Data(seq6).DCCP-Data(seq10)DCCP-Data(seq11).DCCP-Data(seq100)DCCP-Data(seq101)DCCP-Sync(seq7, ack101)DCCP-SyncAck(seq102, ack7)sender has received. As soon as thereceiver gets the acks-of-acks, itcan forget the receiving conditionsof packets that the sender has recognized,thereby reducing the ackvector’s size.DCCP features another importantoption, data drop, which letsthe sender clearly distinguish thecause of each packet loss. The datadrop option comprises a series of 8-bit blocks. The highest bit representswhether the receiver has successfullytransferred the received packetsto the application layer. Afterthe highest bit, a drop code of 3 bitsindicates any causes for the drop,including protocol constraints (0),application not listening (1), receiverbuffer (2), corrupt (3), and deliveredcorrupt (7). The remaining 4 bits arethe run length.Connection termination. Figure 4ashows the process by which DCCPterminates a connection. When theclient intends to terminate a connection,it sends a DCCP-Close packet.Upon receiving this, the server sendsServerTimeExpected seqno[10, 60]Seqno out of rangeSend syncExpected seqno[102, 152]Figure 3. Datagram Congestion Control Protocol data transfer. DCCP can useDCCP-Sync and DCCP-SyncAck packets to synchronize the sequence numbersof both sides.a DCCP-Reset packet to finish theconnection-termination process.When the client receives the DCCP-Reset packet, it terminates the connectionafter waiting for 2MSL. Theprocess by which the server intendsto terminate a connection is similarto the previous description: the serverfirst sends a DCCP-Close packet, thenthe client sends a DCCP-Reset packet,and finally the server waits in theTIMEWAIT state for 2MSL. In general,DCCP achieves the connection terminationprocedure with a DCCP-Closepacket and a DCCP-Reset packet,regardless of which side initializesthis process. However, the servercan decide to let the client remain inthe TIMEWAIT state. In this case, theserver first sends a DCCP-CloseReqpacket to the client; the remainder ofthe process is the same as the precedingcases, as in Figure 4b.Congestion ControlApplications can select suitable congestioncontrol according to their requirements.The server and the clientcan negotiate the congestion-controlSEPTEMBER/OCTOBER 2008 81
StandardsClientServerClientServerOPENOPENOPENOPENCLOSINGDCCP-CloseDCCP-CloseReqCLOSEREQDCCP-ResetCLOSEDLISTENCLOSINGDCCP-CloseTIMEWAIT(2MSL)DCCP-ResetCLOSEDLISTENCLOSEDTimeTIMEWAIT(2MSL)(a)(b)CLOSEDTimeFigure 4. Datagram Congestion Control Protocol connection termination. DCCP uses two- or three-way handshakes toterminate a connection.mechanism they want to use viafeature negotiation options. DCCPcurrently has two defined congestion-controlmechanisms, as mentioned— CCID 2 and CCID 3. CCID2 offers TCP-like congestion control,which is suited to bursty packetflows, whereas CCID 3 offers TFRCcongestion control, which is suited tosmooth packet flows.CCID 2. CCID 2 uses the additiveincrease/multiplicative decrease(AIMD) congestion-control mechanismwhereby the sender adopts acongestion window to control thetransmission rate. The sender adjuststhe window’s value accordingto the information embedded in theacknowledgments. CCID 2 uses threemain integer variables: cwnd (congestionwindow), the maximum allowableamount of outstanding packets;ssthresh (slow-start threshold), athreshold of the congestion windowthat separates slow start from congestionavoidance; and pipe, thenumber of estimated outstandingpackets. These three variables arealmost the same as the variables inSelective Acknowledgement (SACK)TCP, 5 apart from the fact that DCCPuses packets as units, whereas TCPuses bytes as units. The greatest differencebetween CCID 2 and SACKTCP congestion control is that theformer doesn’t execute fast retransmissionand fast recovery becauseit’s an unreliable protocol.Congestion control also retrainsacknowledgments to prevent themfrom causing network congestion.The sender uses the ack ratio featureto dynamically adjust acknowledgments’sending rate from the receiver.The ack ratio is two by default— that is, the receiver replies to anacknowledgment after receiving twopackets. Congestion control for acknowledgmentsis similar to that fordata packets. When the sender detectsan acknowledgment loss, it doublesthe ack ratio, thus halving the acknowledgmentreply rate. When thesender receives acknowledgments ofa congestion-free window, the expectednumber of received acknowledgmentsincreases by one. Becausethe ack ratio is an integer, once reducedby one, the number of receivedacknowledgments will increase bycwnd cwndk = −ack ratio ack ratio −1 .Thus, in reality, when the senderreceives acknowledgments of k congestion-freewindows, the ack ratiodecreases by 1.CCID 3. CCID 3 uses TFRC congestioncontrol. The sender uses the lossevent ratio the receiver measures,calculates the transmission rate Tvia the following formula, and accordinglyadjusts its sending rate:T =S2pRTT +3⎛ p ⎞tRTO3 3 p + p⎝⎜⎠⎟( 1 32 2 ) , (1)8where T is the transmission rate, S isthe packet size, RTT is the round-triptime, t RTOis the retransmission timeout,and p is the loss event ratio.In the initial phase, slow-start,the transmission rate doubles aftereach RTT until the receiver reports apacket loss or ECN marked. Then, thesender leaves the slow-start phaseand uses Equation 1 to calculate thepacket transmission rate allowed inthe next period. CCID 3 expects toreceive throughput similar to TCP ina coexisted environment and obtainsa smooth transmission rate.Table 1 summarizes comparisonsbetween DCCP and TCP, UDP, andthe Stream Control Transmission Protocol(SCTP).Shigeki Takeuchi and his colleaguesobserved the competition between82 www.computer.org/internet/ IEEE INTERNET COMPUTING
Page 6: Transport Protocol with Congestion

DCCP: Transport Protocol with Congestion Control and Unreliability

Create successful ePaper yourself

Delete template?

Save as template?