Commit 2a91aa39 authored by Andrea Bittau's avatar Andrea Bittau Committed by David S. Miller
Browse files

[DCCP] CCID2: Initial CCID2 (TCP-Like) implementation

Original work by Andrea Bittau, Arnaldo Melo cleaned up and fixed several
issues on the merge process.

For now CCID2 was turned the default for all SOCK_DCCP connections, but this
will be remedied soon with the merge of the feature negotiation code.
Signed-off-by: default avatarAndrea Bittau <>
Signed-off-by: default avatarArnaldo Carvalho de Melo <>
Signed-off-by: default avatarDavid S. Miller <>
parent aa5d7df3
......@@ -314,9 +314,9 @@ static inline unsigned int dccp_hdr_len(const struct sk_buff *skb)
/* initial values for each feature */
/* FIXME: for now we're using CCID 3 (TFRC) */
/* FIXME: for now we're using CCID 2 (TCP-Like) */
/* FIXME: for now we're default to 1 but it should really be 0 */
......@@ -430,6 +430,8 @@ struct dccp_sock {
struct timeval dccps_timestamp_time;
__u32 dccps_timestamp_echo;
__u32 dccps_packet_size;
__u16 dccps_l_ack_ratio;
__u16 dccps_r_ack_ratio;
unsigned long dccps_ndp_count;
__u32 dccps_mss_cache;
struct dccp_options dccps_options;
......@@ -24,6 +24,10 @@ config INET_DCCP_DIAG
def_tristate y if (IP_DCCP = y && INET_DIAG = y)
def_tristate m
depends on IP_DCCP
def_bool N
source "net/dccp/ccids/Kconfig"
menu "DCCP Kernel Hacking"
menu "DCCP CCIDs Configuration (EXPERIMENTAL)"
config IP_DCCP_CCID2
depends on IP_DCCP
CCID 2, TCP-like Congestion Control, denotes Additive Increase,
Multiplicative Decrease (AIMD) congestion control with behavior
modelled directly on TCP, including congestion window, slow start,
timeouts, and so forth [RFC 2581]. CCID 2 achieves maximum
bandwidth over the long term, consistent with the use of end-to-end
congestion control, but halves its congestion window in response to
each congestion event. This leads to the abrupt rate changes
typical of TCP. Applications should use CCID 2 if they prefer
maximum bandwidth utilization to steadiness of rate. This is often
the case for applications that are not playing their data directly
to the user. For example, a hypothetical application that
transferred files over DCCP, using application-level retransmissions
for lost packets, would prefer CCID 2 to CCID 3. On-line games may
also prefer CCID 2.
CCID 2 is further described in:
This text was extracted from:
If in doubt, say M.
config IP_DCCP_CCID3
depends on IP_DCCP
......@@ -15,10 +43,15 @@ config IP_DCCP_CCID3
suitable than CCID 2 for applications such streaming media where a
relatively smooth sending rate is of importance.
CCID 3 is further described in [CCID 3 PROFILE]. The TFRC
congestion control algorithms were initially described in RFC 3448.
CCID 3 is further described in:
The TFRC congestion control algorithms were initially described in
RFC 3448.
This text was extracted from draft-ietf-dccp-spec-11.txt.
This text was extracted from:
If in doubt, say M.
......@@ -2,4 +2,8 @@ obj-$(CONFIG_IP_DCCP_CCID3) += dccp_ccid3.o
dccp_ccid3-y := ccid3.o
obj-$(CONFIG_IP_DCCP_CCID2) += dccp_ccid2.o
dccp_ccid2-y := ccid2.o
obj-y += lib/
This diff is collapsed.
* net/dccp/ccids/ccid2.h
* Copyright (c) 2005 Andrea Bittau <>
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* GNU General Public License for more details.
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#ifndef _DCCP_CCID2_H_
#define _DCCP_CCID2_H_
struct ccid2_seq {
u64 ccid2s_seq;
unsigned long ccid2s_sent;
int ccid2s_acked;
struct ccid2_seq *ccid2s_prev;
struct ccid2_seq *ccid2s_next;
/** struct ccid2_hc_tx_sock - CCID2 TX half connection
* @ccid2hctx_ssacks - ACKs recv in slow start
* @ccid2hctx_acks - ACKS recv in AI phase
* @ccid2hctx_sent - packets sent in this window
* @ccid2hctx_lastrtt -time RTT was last measured
* @ccid2hctx_arsent - packets sent [ack ratio]
* @ccid2hctx_ackloss - ack was lost in this win
* @ccid2hctx_rpseq - last consecutive seqno
* @ccid2hctx_rpdupack - dupacks since rpseq
struct ccid2_hc_tx_sock {
int ccid2hctx_cwnd;
int ccid2hctx_ssacks;
int ccid2hctx_acks;
int ccid2hctx_ssthresh;
int ccid2hctx_pipe;
int ccid2hctx_numdupack;
struct ccid2_seq *ccid2hctx_seqbuf;
struct ccid2_seq *ccid2hctx_seqh;
struct ccid2_seq *ccid2hctx_seqt;
long ccid2hctx_rto;
long ccid2hctx_srtt;
long ccid2hctx_rttvar;
int ccid2hctx_sent;
unsigned long ccid2hctx_lastrtt;
struct timer_list ccid2hctx_rtotimer;
unsigned long ccid2hctx_arsent;
int ccid2hctx_ackloss;
u64 ccid2hctx_rpseq;
int ccid2hctx_rpdupack;
int ccid2hctx_sendwait;
struct ccid2_hc_rx_sock {
int ccid2hcrx_data;
#endif /* _DCCP_CCID2_H_ */
......@@ -1081,6 +1081,7 @@ int dccp_v4_init_sock(struct sock *sk)
dp->dccps_mss_cache = 536;
dp->dccps_role = DCCP_ROLE_UNDEFINED;
dp->dccps_service = DCCP_SERVICE_INVALID_VALUE;
dp->dccps_l_ack_ratio = dp->dccps_r_ack_ratio = 1;
return 0;
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment