[DCCP]: Update documentation references.

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.

	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

}

/*

 * 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)

	 * 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

		/*

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

/** 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

	  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.

	  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.

 */

/*

 * This implementation should follow: draft-ietf-dccp-ccid2-10.txt

 * This implementation should follow RFC 4341

 *

 * BUGS:

 * - sequence number wrapping