All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
To: netdev@vger.kernel.org
Cc: David Miller <davem@davemloft.net>,
	Pasi Sarolahti <pasi.sarolahti@nokia.com>
Subject: [PATCH 15/18] [TCP] FRTO: Fake cwnd for ssthresh callback
Date: Mon, 19 Feb 2007 13:38:09 +0200	[thread overview]
Message-ID: <1171885092244-git-send-email-ilpo.jarvinen@helsinki.fi> (raw)
In-Reply-To: <11718850921389-git-send-email-ilpo.jarvinen@helsinki.fi>

TCP without FRTO would be in Loss state with small cwnd. FRTO,
however, leaves cwnd (typically) to a larger value which causes
ssthresh to become too large in case RTO is triggered again
compared to what conventional recovery would do. Because
consecutive RTOs result in only a single ssthresh reduction,
RTO+cumulative ACK+RTO pattern is required to trigger this
event.

A large comment is included for congestion control module writers
trying to figure out what CA_EVENT_FRTO handler should do because
there exists a remote possibility of incompatibility between
FRTO and module defined ssthresh functions.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
 net/ipv4/tcp_input.c |   26 +++++++++++++++++++++++++-
 1 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2c0b387..5d935b1 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1289,7 +1289,31 @@ void tcp_enter_frto(struct sock *sk)
 	    ((icsk->icsk_ca_state == TCP_CA_Loss || tp->frto_counter) &&
 	     !icsk->icsk_retransmits)) {
 		tp->prior_ssthresh = tcp_current_ssthresh(sk);
-		tp->snd_ssthresh = icsk->icsk_ca_ops->ssthresh(sk);
+		/* Our state is too optimistic in ssthresh() call because cwnd
+		 * is not reduced until tcp_enter_frto_loss() when previous FRTO
+		 * recovery has not yet completed. Pattern would be this: RTO,
+		 * Cumulative ACK, RTO (2xRTO for the same segment does not end
+		 * up here twice).
+		 * RFC4138 should be more specific on what to do, even though
+		 * RTO is quite unlikely to occur after the first Cumulative ACK
+		 * due to back-off and complexity of triggering events ...
+		 */
+		if (tp->frto_counter) {
+			u32 stored_cwnd;
+			stored_cwnd = tp->snd_cwnd;
+			tp->snd_cwnd = 2;
+			tp->snd_ssthresh = icsk->icsk_ca_ops->ssthresh(sk);
+			tp->snd_cwnd = stored_cwnd;
+		} else {
+			tp->snd_ssthresh = icsk->icsk_ca_ops->ssthresh(sk);
+		}
+		/* ... in theory, cong.control module could do "any tricks" in
+		 * ssthresh(), which means that ca_state, lost bits and lost_out
+		 * counter would have to be faked before the call occurs. We
+		 * consider that too expensive, unlikely and hacky, so modules
+		 * using these in ssthresh() must deal these incompatibility
+		 * issues if they receives CA_EVENT_FRTO and frto_counter != 0
+		 */
 		tcp_ca_event(sk, CA_EVENT_FRTO);
 	}
 
-- 
1.4.2


  reply	other threads:[~2007-02-19 11:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-19 11:37 [PATCHSET 0/18] FRTO: fixes and small changes + SACK enhanced version Ilpo Järvinen
2007-02-19 11:37 ` [PATCH 1/18] [TCP] FRTO: Incorrectly clears TCPCB_EVER_RETRANS bit Ilpo Järvinen
2007-02-19 11:37   ` [PATCH 2/18] [TCP] FRTO: Separated response from FRTO detection algorithm Ilpo Järvinen
2007-02-19 11:37     ` [PATCH 3/18] [TCP] FRTO: Moved tcp_use_frto from tcp.h to tcp_input.c Ilpo Järvinen
2007-02-19 11:37       ` [PATCH 4/18] [TCP] FRTO: Comment cleanup & improvement Ilpo Järvinen
2007-02-19 11:37         ` [PATCH 5/18] [TCP] FRTO: Consecutive RTOs keep prior_ssthresh and ssthresh Ilpo Järvinen
2007-02-19 11:38           ` [PATCH 6/18] [TCP] FRTO: Use Disorder state during operation instead of Open Ilpo Järvinen
2007-02-19 11:38             ` [PATCH 7/18] [TCP] FRTO: Ignore some uninteresting ACKs Ilpo Järvinen
2007-02-19 11:38               ` [PATCH 8/18] [TCP] FRTO: fixes fallback to conventional recovery Ilpo Järvinen
2007-02-19 11:38                 ` [PATCH 9/18] [TCP] FRTO: Response should reset also snd_cwnd_cnt Ilpo Järvinen
2007-02-19 11:38                   ` [PATCH 10/18] [TCP]: Don't enter to fast recovery while using FRTO Ilpo Järvinen
2007-02-19 11:38                     ` [PATCH 11/18] [TCP] FRTO: frto_counter modulo-op converted to two assignments Ilpo Järvinen
2007-02-19 11:38                       ` [PATCH 12/18] [TCP]: Prevent unrelated cwnd adjustment while using FRTO Ilpo Järvinen
2007-02-19 11:38                         ` [PATCH 13/18] [TCP] FRTO: Entry is allowed only during (New)Reno like recovery Ilpo Järvinen
2007-02-19 11:38                           ` [PATCH 14/18] [TCP] FRTO: Reverse RETRANS bit clearing logic Ilpo Järvinen
     [not found]                             ` <1171885092244-git- send-email-ilpo.jarvinen@helsinki.fi>
2007-02-19 11:38                             ` Ilpo Järvinen [this message]
2007-02-19 11:38                               ` [PATCH 16/18] [TCP]: Prevent reordering adjustments during FRTO Ilpo Järvinen
2007-02-19 11:38                                 ` [PATCH 17/18] [TCP]: SACK enhanced FRTO Ilpo Järvinen
2007-02-19 11:38                                   ` [PATCH 18/18] [TCP] FRTO: Sysctl documentation for SACK enhanced version Ilpo Järvinen

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=1171885092244-git-send-email-ilpo.jarvinen@helsinki.fi \
    --to=ilpo.jarvinen@helsinki.fi \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=pasi.sarolahti@nokia.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.