DCCP protocol discussions
 help / color / mirror / Atom feed
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: [PATCH 5/5]: Fix Request/Response RTT sampling
Date: Wed, 12 Sep 2007 14:35:17 +0000	[thread overview]
Message-ID: <200709121535.17746@strip-the-willow> (raw)

[DCCP]: Fix Request/Response RTT sampling

This fixes a problem with the Request/Response RTT sampling:

The current timestamp is taken after the options are processed, which is
too late if there is anything in the option processing code which takes
more than a trivial amount of time.

One instance is feature negotiation - I found that a full run through all
the option negotiation can take up to 38 ms. (Whether this says something
about feature negotiation or its implementation is a separate issue.)

The real problem (and it was caused by me) is that one does not know
how much time is spent in processing the options - and since DCCP has
space for up to 1020 bytes of options, the situation can be even much worse.

Therefore and since the Linux implementation always sends the required Elapsed
Time option, the timestamp is taken when the function is called, not later.

Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>    
---
 net/dccp/input.c |   12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -329,6 +329,7 @@ static int dccp_rcv_request_sent_state_p
 	if (dh->dccph_type = DCCP_PKT_RESPONSE) {
 		const struct inet_connection_sock *icsk = inet_csk(sk);
 		struct dccp_sock *dp = dccp_sk(sk);
+		long tstamp = dccp_timestamp();
 
 		/* Stop the REQUEST timer */
 		inet_csk_clear_xmit_timer(sk, ICSK_TIME_RETRANS);
@@ -349,13 +350,10 @@ static int dccp_rcv_request_sent_state_p
 		if (dccp_parse_options(sk, skb))
 			goto out_invalid_packet;
 
-		/* Obtain RTT sample from SYN exchange (used by CCID 3) */
-		if (dp->dccps_options_received.dccpor_timestamp_echo) {
-			long d = dccp_timestamp();
-
-			d -= dp->dccps_options_received.dccpor_timestamp_echo;
-			dp->dccps_syn_rtt = dccp_sample_rtt(sk, 10 * d);
-		}
+		/* Obtain usec RTT sample from SYN exchange (used by CCID 3) */
+		if (likely(dp->dccps_options_received.dccpor_timestamp_echo))
+			dp->dccps_syn_rtt = dccp_sample_rtt(sk, 10 * (tstamp -
+			    dp->dccps_options_received.dccpor_timestamp_echo));
 
 		if (dccp_msk(sk)->dccpms_send_ack_vector &&
 		    dccp_ackvec_add(dp->dccps_hc_rx_ackvec, sk,

             reply	other threads:[~2007-09-12 14:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-12 14:35 Gerrit Renker [this message]
2007-09-13  0:28 ` [PATCH 5/5]: Fix Request/Response RTT sampling Ian McDonald
2007-09-13  8:07 ` Gerrit Renker
2007-09-18  7:47 ` Ian McDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200709121535.17746@strip-the-willow \
    --to=gerrit@erg.abdn.ac.uk \
    --cc=dccp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox