openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity

[DCCP]: Update documentation references. 

Updates the references to spec documents throughout the code, taking into
account that

* the DCCP, CCID 2, and CCID 3 drafts all became RFCs in March this year

* RFC 1063 was obsoleted by RFC 1191

* draft-ietf-tcpimpl-pmtud-0x.txt was published as an Informational
  RFC, RFC 2923 on 2000-09-22.

All references verified.

Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
Gerrit Renker 2006-10-24 16:17:51 -07:00 committed by David S. Miller
parent 977a415f2b
commit 0e64e94e47
11 changed files with 27 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
net/dccp/Kconfig
View File

@ -4,15 +4,15 @@ menu "DCCP Configuration (EXPERIMENTAL)"
config IP_DCCP config IP_DCCP
tristate "The DCCP Protocol (EXPERIMENTAL)" tristate "The DCCP Protocol (EXPERIMENTAL)"
---help--- ---help---
Datagram Congestion Control Protocol Datagram Congestion Control Protocol (RFC 4340)
From draft-ietf-dccp-spec-11 <http://www.icir.org/kohler/dcp/draft-ietf-dccp-spec-11.txt>. From http://www.ietf.org/rfc/rfc4340.txt:
The Datagram Congestion Control Protocol (DCCP) is a transport The Datagram Congestion Control Protocol (DCCP) is a transport
protocol that implements bidirectional, unicast connections of protocol that implements bidirectional, unicast connections of
congestion-controlled, unreliable datagrams. It should be suitable congestion-controlled, unreliable datagrams. It should be suitable
for use by applications such as streaming media, Internet telephony, for use by applications such as streaming media, Internet telephony,
and on-line games and on-line games.
To compile this protocol support as a module, choose M here: the To compile this protocol support as a module, choose M here: the
module will be called dccp. module will be called dccp.

12
net/dccp/ackvec.c
View File

@ -113,7 +113,7 @@ int dccp_insert_option_ackvec(struct sock *sk, struct sk_buff *skb)
memcpy(to, from, len); memcpy(to, from, len);
/* /*
* From draft-ietf-dccp-spec-11.txt: * From RFC 4340, A.2:
* *
* For each acknowledgement it sends, the HC-Receiver will add an * For each acknowledgement it sends, the HC-Receiver will add an
* acknowledgement record. ack_seqno will equal the HC-Receiver * acknowledgement record. ack_seqno will equal the HC-Receiver
@ -224,7 +224,7 @@ static inline int dccp_ackvec_set_buf_head_state(struct dccp_ackvec *av,
} }
/* /*
* Implements the draft-ietf-dccp-spec-11.txt Appendix A * Implements the RFC 4340, Appendix A
*/ */
int dccp_ackvec_add(struct dccp_ackvec *av, const struct sock *sk, int dccp_ackvec_add(struct dccp_ackvec *av, const struct sock *sk,
const u64 ackno, const u8 state) const u64 ackno, const u8 state)
@ -237,7 +237,7 @@ int dccp_ackvec_add(struct dccp_ackvec *av, const struct sock *sk,
* We may well decide to do buffer compression, etc, but for now lets * We may well decide to do buffer compression, etc, but for now lets
* just drop. * just drop.
* *
* From Appendix A: * From Appendix A.1.1 (`New Packets'):
* *
* Of course, the circular buffer may overflow, either when the * Of course, the circular buffer may overflow, either when the
* HC-Sender is sending data at a very high rate, when the * HC-Sender is sending data at a very high rate, when the
@ -274,9 +274,9 @@ int dccp_ackvec_add(struct dccp_ackvec *av, const struct sock *sk,
/* /*
* A.1.2. Old Packets * A.1.2. Old Packets
* *
* When a packet with Sequence Number S arrives, and * When a packet with Sequence Number S <= buf_ackno
* S <= buf_ackno, the HC-Receiver will scan the table * arrives, the HC-Receiver will scan the table for
* for the byte corresponding to S. (Indexing structures * the byte corresponding to S. (Indexing structures
* could reduce the complexity of this scan.) * could reduce the complexity of this scan.)
*/ */
u64 delta = dccp_delta_seqno(ackno, av->dccpav_buf_ackno); u64 delta = dccp_delta_seqno(ackno, av->dccpav_buf_ackno);

3
net/dccp/ackvec.h
View File

@ -28,8 +28,7 @@
/** struct dccp_ackvec - ack vector /** struct dccp_ackvec - ack vector
* *
* This data structure is the one defined in the DCCP draft * This data structure is the one defined in RFC 4340, Appendix A.
* Appendix A.
* *
* @dccpav_buf_head - circular buffer head * @dccpav_buf_head - circular buffer head
* @dccpav_buf_tail - circular buffer tail * @dccpav_buf_tail - circular buffer tail

17
net/dccp/ccids/Kconfig
View File

@ -22,11 +22,11 @@ config IP_DCCP_CCID2
for lost packets, would prefer CCID 2 to CCID 3. On-line games may for lost packets, would prefer CCID 2 to CCID 3. On-line games may
also prefer CCID 2. also prefer CCID 2.
CCID 2 is further described in: CCID 2 is further described in RFC 4341,
http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid2-10.txt http://www.ietf.org/rfc/rfc4341.txt
This text was extracted from: This text was extracted from RFC 4340 (sec. 10.1),
http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt http://www.ietf.org/rfc/rfc4340.txt
If in doubt, say M. If in doubt, say M.
@ -53,15 +53,14 @@ config IP_DCCP_CCID3
suitable than CCID 2 for applications such streaming media where a suitable than CCID 2 for applications such streaming media where a
relatively smooth sending rate is of importance. relatively smooth sending rate is of importance.
CCID 3 is further described in: CCID 3 is further described in RFC 4342,
http://www.ietf.org/rfc/rfc4342.txt
http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid3-11.txt.
The TFRC congestion control algorithms were initially described in The TFRC congestion control algorithms were initially described in
RFC 3448. RFC 3448.
This text was extracted from: This text was extracted from RFC 4340 (sec. 10.2),
http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt http://www.ietf.org/rfc/rfc4340.txt
If in doubt, say M. If in doubt, say M.

2
net/dccp/ccids/ccid2.c
View File

@ -23,7 +23,7 @@
*/ */
/* /*
* This implementation should follow: draft-ietf-dccp-ccid2-10.txt * This implementation should follow RFC 4341
* *
* BUGS: * BUGS:
* - sequence number wrapping * - sequence number wrapping

3
net/dccp/ccids/ccid3.c
View File

@ -379,8 +379,7 @@ static void ccid3_hc_tx_packet_sent(struct sock *sk, int more, int len)
packet->dccphtx_seqno = dp->dccps_gss; packet->dccphtx_seqno = dp->dccps_gss;
/* /*
* Check if win_count have changed * Check if win_count have changed
* Algorithm in "8.1. Window Counter Valuer" in * Algorithm in "8.1. Window Counter Value" in RFC 4342.
* draft-ietf-dccp-ccid3-11.txt
*/ */
quarter_rtt = timeval_delta(&now, &hctx->ccid3hctx_t_last_win_count); quarter_rtt = timeval_delta(&now, &hctx->ccid3hctx_t_last_win_count);
if (likely(hctx->ccid3hctx_rtt > 8)) if (likely(hctx->ccid3hctx_rtt > 8))

2
net/dccp/dccp.h
View File

@ -50,7 +50,7 @@ extern void dccp_time_wait(struct sock *sk, int state, int timeo);
#define DCCP_TIMEWAIT_LEN (60 * HZ) /* how long to wait to destroy TIME-WAIT #define DCCP_TIMEWAIT_LEN (60 * HZ) /* how long to wait to destroy TIME-WAIT
* state, about 60 seconds */ * state, about 60 seconds */
/* draft-ietf-dccp-spec-11.txt initial RTO value */ /* RFC 1122, 4.2.3.1 initial RTO value */
#define DCCP_TIMEOUT_INIT ((unsigned)(3 * HZ)) #define DCCP_TIMEOUT_INIT ((unsigned)(3 * HZ))
/* Maximal interval between probes for local resources. */ /* Maximal interval between probes for local resources. */

4
net/dccp/input.c
View File

@ -216,11 +216,11 @@ static int __dccp_rcv_established(struct sock *sk, struct sk_buff *skb,
dccp_send_sync(sk, DCCP_SKB_CB(skb)->dccpd_seq, dccp_send_sync(sk, DCCP_SKB_CB(skb)->dccpd_seq,
DCCP_PKT_SYNCACK); DCCP_PKT_SYNCACK);
/* /*
* From the draft: * From RFC 4340, sec. 5.7
* *
* As with DCCP-Ack packets, DCCP-Sync and DCCP-SyncAck packets * As with DCCP-Ack packets, DCCP-Sync and DCCP-SyncAck packets
* MAY have non-zero-length application data areas, whose * MAY have non-zero-length application data areas, whose
* contents * receivers MUST ignore. * contents receivers MUST ignore.
*/ */
goto discard; goto discard;
} }

4
net/dccp/ipv4.c
View File

@ -183,7 +183,7 @@ static inline void dccp_do_pmtu_discovery(struct sock *sk,
dccp_sync_mss(sk, mtu); dccp_sync_mss(sk, mtu);
/* /*
* From: draft-ietf-dccp-spec-11.txt * From RFC 4340, sec. 14.1:
* *
* DCCP-Sync packets are the best choice for upward * DCCP-Sync packets are the best choice for upward
* probing, since DCCP-Sync probes do not risk application * probing, since DCCP-Sync probes do not risk application
@ -733,7 +733,7 @@ static void dccp_v4_ctl_send_reset(struct sk_buff *rxskb)
dccp_hdr_reset(skb)->dccph_reset_code = dccp_hdr_reset(skb)->dccph_reset_code =
DCCP_SKB_CB(rxskb)->dccpd_reset_code; DCCP_SKB_CB(rxskb)->dccpd_reset_code;
/* See "8.3.1. Abnormal Termination" in draft-ietf-dccp-spec-11 */ /* See "8.3.1. Abnormal Termination" in RFC 4340 */
seqno = 0; seqno = 0;
if (DCCP_SKB_CB(rxskb)->dccpd_ack_seq != DCCP_PKT_WITHOUT_ACK_SEQ) if (DCCP_SKB_CB(rxskb)->dccpd_ack_seq != DCCP_PKT_WITHOUT_ACK_SEQ)
dccp_set_seqno(&seqno, DCCP_SKB_CB(rxskb)->dccpd_ack_seq + 1); dccp_set_seqno(&seqno, DCCP_SKB_CB(rxskb)->dccpd_ack_seq + 1);

2
net/dccp/ipv6.c
View File

@ -550,7 +550,7 @@ static void dccp_v6_ctl_send_reset(struct sk_buff *rxskb)
dccp_hdr_reset(skb)->dccph_reset_code = dccp_hdr_reset(skb)->dccph_reset_code =
DCCP_SKB_CB(rxskb)->dccpd_reset_code; DCCP_SKB_CB(rxskb)->dccpd_reset_code;
/* See "8.3.1. Abnormal Termination" in draft-ietf-dccp-spec-11 */ /* See "8.3.1. Abnormal Termination" in RFC 4340 */
seqno = 0; seqno = 0;
if (DCCP_SKB_CB(rxskb)->dccpd_ack_seq != DCCP_PKT_WITHOUT_ACK_SEQ) if (DCCP_SKB_CB(rxskb)->dccpd_ack_seq != DCCP_PKT_WITHOUT_ACK_SEQ)
dccp_set_seqno(&seqno, DCCP_SKB_CB(rxskb)->dccpd_ack_seq + 1); dccp_set_seqno(&seqno, DCCP_SKB_CB(rxskb)->dccpd_ack_seq + 1);

2
net/dccp/options.c
View File

@ -215,7 +215,7 @@ int dccp_parse_options(struct sock *sk, struct sk_buff *skb)
elapsed_time); elapsed_time);
break; break;
/* /*
* From draft-ietf-dccp-spec-11.txt: * From RFC 4340, sec. 10.3:
* *
* Option numbers 128 through 191 are for * Option numbers 128 through 191 are for
* options sent from the HC-Sender to the * options sent from the HC-Sender to the