We discuss some of DCCP’s contribution towards "unreliable congestion control”. In section 2, we try to motivate (with this paper’s motivation) the need for a DCCP like transport. In section 3, we summarize their key congestion steps and finally, we comment on their approach in section 4.
1. TCP does in-order and reliable delivery: TCP believes in in-order delivery of packets but applications (“such as Internet telephony, streaming video and on-line games”) that DCCP will carry gives priority to current packet and there is less priority to in order delivery. Again, TCP’s concern is of reliable packet delivery. For this it has to retransmit in case of packet loss. In assignment11 we show that because of all the stream and datagram traffic in the network it is having trouble in its transmission rate. Although 80% of current internet traffic is TCP, udp will have increasing traffic in the future. This will hamper such application’s smooth traffic rate requirement.
SCTP has a solution for out-of order delivery. It does so by breaking the streams into pieces but in each piece of stream, in-order delivery has to be ensured. So, it may not solve such application’s need.
2. UDP is losing Packets: UDP just adds 8-byte header to IP, mainly to ensure multiplexing. UDP has no connection setup, no feedback loop, no congestion and flow control. It is losing packets. In assignment11 we show that it is affected by both tcp and other udp traffic. As there is no feedback, it does not know when a queue is free so it can send more packets and when there is no space so it can reduce transmission rate without too much hampering the timeliness requirement.
The need for a protocol to address “unreliable congestion control” stems from this fact that packets using UDP is prone to packet loss.
3. Can ECN help: Congestion is mainly caused by dropping of packets by routers. Routers deal with network layer protocol (IP). Transport layer just predicts what might happen in the network. Our notion of network layer suggest that IP layer just passes the TPDU to transport without telling anything about things that go in its lower level. However, this is not the case with IP header. It has a bit to set called ECN (explicit congestion notification). A router can set this bit without dropping this packet to suggest that it is going to drop packets in the future. TCP receiver can look at this IP header bit and tell the TCP sender as though a packet has been dropped and trigger a congestion control.
UDP has no feedback so it cannot use ECN. However, can this use by TCP solve the congestion problem? The answer is ‘No’. This is because not all the packets travel the same congested router. Indeed to motivate and design DCCP, negotiation mechanism to use ECN is important.
4. Can’t current Application Layer Protocol solve the problem?: Yes they can. But the problem is it is “not part of most application’s core need”. Again, the ECN bit is in the IP header and to access it from application layer is too complicated.
Again, we have to decide whether deciding congestion mechanism from application is a good idea or not.
5. Why not control in the Network Layer: This is because packets reach from source to destination in different paths and on different routers.
1. Feature negotiation: DCCP clearly shows that feature negotiation, especially, negotiation of congestion mechanism is application specific and TCP.
2. Reliable acknowledgement: This paper nicely points out that TCP like congestion control based on acknowledgement does not work for DCCP. For TCP it works because an ACK of a packet means all the other packets were received but DCCP does not guarantee reliability. Here the cumulative acknowledgement does not say which packets are received. Taking congestion-action seeing an ack, may turn out to be unnecessary where congestion is long gone. Hence, DCCP takes measure so that the receiver knows what the current state is. For that, in DCCP when a sender tells that it received a packet to the receiver, the receiver knows that the packets ack options are received and it can throw its previous state as in the ack.
3. Bidirectionality: Although DCCP connection is bidirectional, the functionality is asymmetric (because of the asymmetric role played by server and client). The reasons for the Bidirectionality is three fold: 1. We don’t have to think of client-server role as it can change, 2. Acknowledgement can be piggybacked with data packets and 3. For NAT and firewall traversal, single connection “initiated from inside” is a requirement.
DCCP’s bidirectionality is achieved by two half connections.
4. TCP-like congestion control: Being an unreliable protocol DCCP has the luxury not to do flow control. Nevertheless, it does congestion control by reliably sending “Ack Vector” from receiver to sender and uses TCP like congestion control.
5. TFRC congestion control: This follows the way of TFRC to vary the sending rate depending on receiver’s report. There is no need for reliable ack.
1. There is no implementation or evaluation
2. DCCP header size and its usage: TCP has 20 bytes and UDP has 8 bytes of header. DCCP has 16 bytes when there is acknowledgement, although most of the time ack won’t be present and the header will be 12 bytes. However, the packets which doen’t have ack, doesn’t have any option field either!!!. Therefore, without even using ack it will need 16 bytes of header to accommodate options field. The problem is with “Low per-packet overhead” requirement.
3. TFRC Congestion Control: DCCP has a good way to negotiate congestion mechanism but one variation of TFRC is mentioned in this paper. For applications requiring small packets with a minimum interval may require TFRC-SP and for applications that gives importance to the change of packet size rather than packet per second can use TFRC-PS.
4. Control of Congestion Decision to Application Layer: DCCP’s congestion mechanism is done depending on the application’s requirement. So far in the current practice of socket, there is not mechanism for application layer to tell transport which sort of congestion it wants to use.
5. Congestion mechanism negotiation at the startup: We really need to figure out if congestion mechanism negotiation at startup is actually the solution; mechanism might change in middle of the transmission or at the end.
6. Use of Sequence number in each packet: Per packet seq# in DCCP guarantees congestion control from reverse side that is the congestion control of acknowledgements. But this is a burden and UDP never had such seq#. This paper suggests that use of such seq# will prove effective against replay attacks and the receiver will be able to distinguish from old packets. Firstly, for an unreliable protocol with no flow control this is a luxury. Secondly, we need to figure out whether the application that concerns DCCP really needs to be resistant to replay attacks.
We thought RTP and RTCP like transport over UDP using TFRC like congestion control can save our day. In fact, we need a transport protocol which binds TFRC (and its variations depending on application need) congestion control to UDP both in its headers and communications. DCCP can do that. This paper rightly pointed out, “Carrying RTP over DCCP seems a cleaner separation of functionality.”