Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-12-29 06:12:08 +00:00
Code Issues Packages Projects Releases Wiki Activity

[DCCP]: Update documentation references.

Browse Source 
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
tristate "The DCCP Protocol (EXPERIMENTAL)"
---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
protocol that implements bidirectional, unicast connections of
congestion-controlled, unreliable datagrams. It should be suitable
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
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);
/*
* From draft-ietf-dccp-spec-11.txt:
* From RFC 4340, A.2:
*
* For each acknowledgement it sends, the HC-Receiver will add an
* 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,
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
* just drop.
*
* From Appendix A:
* From Appendix A.1.1 (`New Packets'):
*
* Of course, the circular buffer may overflow, either 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
*
* When a packet with Sequence Number S arrives, and
* S <= buf_ackno, the HC-Receiver will scan the table
* for the byte corresponding to S. (Indexing structures
* When a packet with Sequence Number S <= buf_ackno
* arrives, the HC-Receiver will scan the table for
* the byte corresponding to S. (Indexing structures
* could reduce the complexity of this scan.)
*/
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
*
* This data structure is the one defined in the DCCP draft
* Appendix A.
* This data structure is the one defined in RFC 4340, Appendix A.
*
* @dccpav_buf_head - circular buffer head
* @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
also prefer CCID 2.
CCID 2 is further described in:
http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid2-10.txt
CCID 2 is further described in RFC 4341,
http://www.ietf.org/rfc/rfc4341.txt
This text was extracted from:
http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt
This text was extracted from RFC 4340 (sec. 10.1),
http://www.ietf.org/rfc/rfc4340.txt
If in doubt, say M.
@ -53,15 +53,14 @@ 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:
http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid3-11.txt.
CCID 3 is further described in RFC 4342,
http://www.ietf.org/rfc/rfc4342.txt
The TFRC congestion control algorithms were initially described in
RFC 3448.
This text was extracted from:
http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt
This text was extracted from RFC 4340 (sec. 10.2),
http://www.ietf.org/rfc/rfc4340.txt
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:
* - 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;
/*
* Check if win_count have changed
* Algorithm in "8.1. Window Counter Valuer" in
* draft-ietf-dccp-ccid3-11.txt
* Algorithm in "8.1. Window Counter Value" in RFC 4342.
*/
quarter_rtt = timeval_delta(&now, &hctx->ccid3hctx_t_last_win_count);
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
* 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))
/* Maximal interval between probes for local resources. */

4
net/dccp/input.c
View File

@ -216,11 +216,11 @@ send_sync:
dccp_send_sync(sk, DCCP_SKB_CB(skb)->dccpd_seq,
DCCP_PKT_SYNCACK);
/*
* From the draft:
* From RFC 4340, sec. 5.7
*
* As with DCCP-Ack packets, DCCP-Sync and DCCP-SyncAck packets
* MAY have non-zero-length application data areas, whose
* contents * receivers MUST ignore.
* contents receivers MUST ignore.
*/
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);
/*
* From: draft-ietf-dccp-spec-11.txt
* From RFC 4340, sec. 14.1:
*
* DCCP-Sync packets are the best choice for upward
* 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_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;
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);

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_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;
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);

2
net/dccp/options.c
View File

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