: Sample RTT from SYN exchange

[DCCP]: Sample RTT from SYN exchange

Function:
---------
This patch acquires the RTT of the initial SYN (Request/Response) exchange and stores it in an unused field of dccp_sock.

Purpose:
--------
The purpose is primarily to provide an initial RTT sample for CCIDs. CCID 3 in particular benefits from such a sample; using the RTT of the SYN exchange is recommended in an erratum to RFC 4342, and in draft-ietf-dccp-rfc3448bis.

Implementation note:
--------------------
Double use is made of the `icsk_ack.lrcvtime' field by #defining an alias for it. This is justified (1) by exploiting that Acks are only meaningful when the client has reached the OPEN state and the alias is used before reaching this state and
(2) since there is currently no other use for this field in the entire DCCP code. (NB: Since the RTT sample is currently used only by CCID 3, it could be wrapped in Kconfig #ifdef options, but this clutters code and so has not been done.)

---
 include/linux/dccp.h |    2 ++
 net/dccp/input.c     |    8 ++++++++
 net/dccp/options.c   |    8 ++++++++
 3 files changed, 18 insertions(+)

@@ -476,10 +476,12 @@ struct dccp_ackvec;
  * @dccps_hc_rx_insert_options -
  * @dccps_hc_tx_insert_options -
  * @dccps_xmit_timer - timer for when CCID is not ready to send
+ * @dccps_syn_rtt - RTT sample from Request/Response exchange (in usecs)
  */
 struct dccp_sock {
 	/* inet_connection_sock has to be the first member of dccp_sock */
 	struct inet_connection_sock	dccps_inet_connection;
+#define dccps_syn_rtt			dccps_inet_connection.icsk_ack.lrcvtime
 	__u64				dccps_swl;
 	__u64				dccps_swh;
 	__u64				dccps_awl;

@@ -565,6 +565,14 @@ int dccp_insert_options(struct sock *sk,
 	    dccp_insert_options_feat(sk, skb))
 		return -1;
 
+	/*
+	 * Obtain RTT sample from Request/Response exchange.
+	 * This is currently used in CCID 3 initialisation.
+	 */
+	if (DCCP_SKB_CB(skb)->dccpd_type = DCCP_PKT_REQUEST &&
+	    dccp_insert_option_timestamp(sk, skb))
+		return -1;
+
 	/* XXX: insert other options when appropriate */
 
 	if (DCCP_SKB_CB(skb)->dccpd_opt_len != 0) {

@@ -353,6 +353,14 @@ static int dccp_rcv_request_sent_state_p
 		/* Make sure socket is routed, for correct metrics. */
 		icsk->icsk_af_ops->rebuild_header(sk);
 
+		/* Obtain RTT sample from SYN exchange (used by CCID 3) */
+		if (dp->dccps_options_received.dccpor_timestamp_echo) {
+			struct timeval now;
+
+			do_gettimeofday(&now);
+			dp->dccps_syn_rtt = dccp_sample_rtt(sk, &now, NULL);
+		}
+
 		if (!sock_flag(sk, SOCK_DEAD)) {
 			sk->sk_state_change(sk);
 			sk_wake_async(sk, 0, POLL_OUT);

My initial thoughts on this is that the concept is quite similar to mine as we both get it from request/response feedback. Totally agree that it is the right thing to do.

My code seems simpler but yours seems better structured. Not that that matters anyway!!

I haven't read the code properly so this is probably a stupid question. Doesn't this rely on the receiver sending back the RTT which it can't know at that point of time?? It's only had the request then so rtt can only be determined by the receiver. But I could be wrong here and I will go back and read the code/rfcs when back at home.

Ian

Web: http://wand.net.nz/~iam4
Blog: http://iansblog.jandi.co.nz
WAND Network Research Group

Quoting Ian McDonald:

|  Doesn't this rely on the receiver sending back the RTT which
|  it can't know at that point of time?? It's only had the request then
|  so rtt can only be determined by the receiver. But I could be wrong
|  here and I will go back and read the code/rfcs when back at home.

It samples the RTT from the initial SYN (Request/Response) exchange:
* the client adds a timestamp option when sending its Request
* it then enters the REQUEST state and waits for the matching Response
* when the server replies with a timestamp echo option, the client subtracts this value from t_now, and also the elapsed_time (if supplied)
* if there is no timestamp echo option in the reply, it does not set the field
Using the SYN exchange is suggested both in the erratum to RFC 4342 and in draft 3448bis.

- Gerrit