Datagram Congestion Control Protocol (DCCP)

Transcription

1 Datagram Congestion Control Protocol (DCCP) Chung, Kwangsue June,

2 Contents Introduction & Motivation DCCP Mechanisms Current Issues & Implementations 2

3 DCCP: Introduction & Motivation 3

4 Introduction TCP-like congestion control isn t appropriate for all applications A large increase in application using UDP that have been reluctant to use congestion control Congestion control is important functioning of the Internet An alternative UDP or An unreliable alternative TCP is required Provide a simple minimal congestion control protocol DCCP 4

5 Motivation A steady growth of applications that generate long-lived flows of UDP datagrams Internet telephony, streaming video and on-line games Preference for timeliness over reliability TCP can introduce arbitrary delay because of its reliability and in-order delivery requirements Thus, these applications use non-congestion-controlled 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 5

6 Motivation : Application requirements Choice of congestion control mechanism TCP-like congestion control, TFRC Low per-packet overhead To achieve low delay and quick response time ECN support This is particularly desirable for applications with tight timing constraints 6

7 Motivation : Design alternatives Congestion control above UDP Implementing congestion control onto applications It s hard to implement / Bad interoperability Congestion control below UDP This approach can t access multiple congestion control There is still complexity up to the application (because of feedback control) Congestion control at transport layer Modify TCP : changing semantics? serious confusion at firewalls and monitoring system Unreliable SCTP : SCTP is hardly minimal, and doesn t allow congestion control negotiation 7

8 DCCP: Mechanisms 8

9 Main features Congestion control ID (CCID) Negotiation of congestion control algorithm Half-connection : Two CCIDs per connection Low overhead as possible DCCP is intended to be used by applications that currently use UDP without E2E congestion control Scope : IP/DCCP/RTP 9

10 Packet format Generic packet header Source Port Destination Port Type CCval Sequence Number Data offset #NDP CSLen - CCval : sending CCID information - Data offset : padding - #NDP : Number of Non-Data Packets - CSLen : checksum length - Checksum Checksum 10

11 Packet types 16 types are possible (4bit) Currently 9 types are used DCCP-Request DCCP-Response DCCP-Data DCCP-Ack DCCP-DataAck : piggybacking DCCP-CloseReq DCCP-Close DCCP-Reset DCCP-move : for mobility, multihoming 11

12 Half-connection Half-connection form A to B Half-connection form B to A Full DCCP session with Bidirectional data Two logical half connection in a single connection Feature negotiation for the two half-connection is completely independent, and may happen simultaneously For example, the two-half connection use different congestion control mechanisms 12

13 CCID Congestion Control Identifier (0 ~ 255) During connection setup, and optionally thereafter, endpoints negotiate congestion control mechanisms CCIDs are defined as yet, CCID Meaning 0 Reserved 1 Unspecified Sender-Based congestion control 2 TCP-like congestion control (AIMD) 3 TFRC congestion control (TCP-SACK) 13

14 CCID2 : TCP-like DCCP s TCP-like congestion control framework differs from that of TCP Sender s congestion window is still used But, it can not use a cumulative acknowledgement field to control this Other mechanism If packets are lost, the sender halves it s sending rate appropriately For reliable transmission, using an Ack Vector and acks-ofacks DCCP can detect reverse-path congestion using per-packet sequence numbers, and respond to it appropriate 14

15 CCID3 : TFRC Instead of a congestion window, a CCID3 sender uses a sending rate Receiver sends feedback to the sender roughly once per round-trip-time reporting the loss event rate calculated by the receiver The sender uses the reported loss event rate to determine its sending rate T R 2 t (3 32 p 2 RTO bp 3 s 3bp ) p(1 8 ) 15

16 CCID negotiation A B B A : Change (1, 2, 3) Asks the sender to use CCID 1, although CCIDs 2 and 3 are also acceptable. A B : Confirm (1, 2, 3) The sender is using CCID 1, but that CCIDs 2 or 3 might also be acceptable A B : Prefer (2, 3) CCID 1 is not acceptable, but, It would prefer CCID 2 or 3 Renegotiation 16

17 17 DCCP state diagram

18 Connection overview Two ends, (potentially) two-way data transfer Explicit connection setup and teardown Request / Response, CloseReq / Reset Data transfer and most feature negotiation use Data and DataAck Data = data only DataAck = data + Ack 18

19 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? TFRC options: loss event rate 19

20 Example of DCCP-connection (1/3) A B 0: Request, Ask(CCID 2) B A 100: Response[0], Answer(CCID 2), Ask(CCID 0) A B 1: DataAck[100], Answer(CCID 0) B A 101: Data, [media data] B A 102: Data, [media data] A B 2: DataAck[102], Ack Vector( ) 20

21 Example of DCCP-connection (2/3) B A 103: Data, [media data] B A 104: Data, [media data] * LOST * B A 105: Data, [media data] B A 106: DataAck[2], [media data] A B 3: DataAck[103], Ack Vector( ) A B 4: DataAck[106], Ack Vector( X ) 21

22 Example of DCCP-connection (3/3) B A 107: DataAck[4], [media data] B A 108: Data, [media data] A B 5: DataAck[108], Ack Vector( )... B A 200: CloseReq[80] A B 81: Close[200] B A 201: Reset[81] 22

23 Explicit congestion notification DCCP is fully ECN-aware. Each CCID specifies how its endpoints respond to ECN marks ECN capable feature To inform its partner that it cannot read ECN bits from received IP headers, so the partner must not set ECN-Capable Transport on its packets. ECN capable 1 / ECN capable 0 New connection start with ECN capable 1 23

24 Multihoming and mobility DCCP provides primitive support for multihoming and mechanism Transferring a connection endpoint from one address to another When the moving endpoint gets a new address, it sends a DCCP-Move packet from that address to the stationary endpoint Then, the stationary endpoint changes its connection state to use the new address Mobility capable feature To inform its partner that it would like to be able to change its address and/or port during the course of the connection Mobility Capable 0 / Mobility Capable 1 24

25 DCCP: Current Issues /Implementations 25

26 RTP-over-DCCP RTP-over-DCCP vs. RTP-over-UDP Potential sources of overhead in the RTP-over-DCCP Duplicated acknowledgement/sequence number with RTP Using DCCP s Ack Vector & sequence number DCCP s Sequence number-#ndp = Sequence number of RTP 4bytes per packet are added relative to RTP-over-UDP (when CCID3, TFRC) RTP-over-DCCP have small overhead However, more research is needed about RTP optimization 26

27 Partial 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 : CSLen=0, DCCP/IP header, but not payload Link-corrupt bit pass up to application Link Layer interactions Link layer checksums are stronger than IP checksum Unless link layer will support partial checksum? Device driver modification 27

28 Guarding against misbehavior Misbehaving-receiver attacks Greedy endpoint tries to get more than its fair share of network bandwidth Hijacking attacks A man in middle takes over a connection Denial-of-service (DoS) attacks Malicious or broken partner sends useless messages that take up CPU or memory resources Several issues were more difficult than in TCP because of DCCP s unreliability Nevertheless, DCCP seems at least as protected against misbehavior as TCP 28

29 Implementations Prototype implementations Patrick McManus's Linux kernel DCCP ( A user-level DCCP from Berkeley ( Present works ICIR Sun RealNetworks Deval Mehta Vladimir Moltchanov, Nokia 29

30 Testing for friendliness Measured friendliness of DCCP with CCID3 with respect to increasing TCP connections 1 DCCP 1 TCP Exhibits relatively fair rate changes with respect to background flows 1 DCCP 3 TCP 30

31 References DCCP homepage IETF DCCP working group cp-charter.html DCCP mailing list page 31