[RFC] cubic: backoff after slow start

[Stephen Hemminger]

CUBIC takes several unnecessary iterations to converge out of slow start. This
is most noticable over a link where the bottleneck queue size is much larger 
than BDP,
and the sender has to fill the pipe in slow start before the first loss. 
Typical
consumer broadband links seem to have large (up to 2secs) of queue that needs
to get filled before the first loss.

A possible fix is to use a beta of .5 (same as original TCP) when leaving
slow start.  Originally, the Linux version didn't do slow start so it probably
never was observed.

--- a/net/ipv4/tcp_cubic.c  2007-08-02 12:16:22.0 +0100
+++ b/net/ipv4/tcp_cubic.c  2007-08-03 15:57:12.0 +0100
@@ -289,7 +289,11 @@ static u32 bictcp_recalc_ssthresh(struct
 
ca-loss_cwnd = tp-snd_cwnd;
 
-   return max((tp-snd_cwnd * beta) / BICTCP_BETA_SCALE, 2U);
+   /* Initial backoff when leaving slow start */
+   if (tp-snd_ssthresh == 0x7fff)
+   return max(tp-snd_cwnd  1U, 2U);
+   else
+   return max((tp-snd_cwnd * beta) / BICTCP_BETA_SCALE, 2U);
 }
 
 static u32 bictcp_undo_cwnd(struct sock *sk)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] cubic: backoff after slow start

[Injong Rhee]

Hi Stephen,
We have been working on slow start and we have a nice solution for this. We 
will send you a patch and test results.

Thanks
Injong


- Original Message - 
From: Stephen Hemminger [EMAIL PROTECTED]

To: Injong Rhee [EMAIL PROTECTED]; Sangtae Ha [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
Sent: Tuesday, August 07, 2007 2:37 PM
Subject: [RFC] cubic: backoff after slow start


CUBIC takes several unnecessary iterations to converge out of slow start. 
This
is most noticable over a link where the bottleneck queue size is much 
larger than BDP,
and the sender has to fill the pipe in slow start before the first loss. 
Typical
consumer broadband links seem to have large (up to 2secs) of queue that 
needs

to get filled before the first loss.

A possible fix is to use a beta of .5 (same as original TCP) when leaving
slow start.  Originally, the Linux version didn't do slow start so it 
probably

never was observed.

--- a/net/ipv4/tcp_cubic.c 2007-08-02 12:16:22.0 +0100
+++ b/net/ipv4/tcp_cubic.c 2007-08-03 15:57:12.0 +0100
@@ -289,7 +289,11 @@ static u32 bictcp_recalc_ssthresh(struct

 ca-loss_cwnd = tp-snd_cwnd;

- return max((tp-snd_cwnd * beta) / BICTCP_BETA_SCALE, 2U);
+ /* Initial backoff when leaving slow start */
+ if (tp-snd_ssthresh == 0x7fff)
+ return max(tp-snd_cwnd  1U, 2U);
+ else
+ return max((tp-snd_cwnd * beta) / BICTCP_BETA_SCALE, 2U);
}

static u32 bictcp_undo_cwnd(struct sock *sk)








-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html