All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Heffner <jheffner@psc.edu>
To: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Cc: David Miller <davem@davemloft.net>,
	Netdev <netdev@vger.kernel.org>, Matt Mathis <mathis@psc.edu>
Subject: Re: [PATCH net-2.6 0/3]: Three TCP fixes
Date: Tue, 04 Dec 2007 16:17:29 -0500	[thread overview]
Message-ID: <4755C3E9.4090609@psc.edu> (raw)
In-Reply-To: <Pine.LNX.4.64.0712042252450.12072@kivilampi-30.cs.helsinki.fi>

Ilpo Järvinen wrote:
> On Tue, 4 Dec 2007, John Heffner wrote:
> 
>> Ilpo Järvinen wrote:
>>> ...I'm still to figure out why tcp_cwnd_down uses snd_ssthresh/2
>>> as lower bound even though the ssthresh was already halved, so snd_ssthresh
>>> should suffice.
>> I remember this coming up at least once before, so it's probably worth a
>> comment in the code.  Rate-halving attempts to actually reduce cwnd to half
>> the delivered window.  Here, cwnd/4 (ssthresh/2) is a lower bound on how far
>> rate-halving can reduce cwnd.  See the "Bounding Parameters" section of
>> <http://www.psc.edu/networking/papers/FACKnotes/current/>.
> 
> Thanks for the info! Sadly enough it makes NewReno recovery quite 
> inefficient when there are enough losses and high BDP link (in my case 
> 384k/200ms, BDP sized buffer). There might be yet another bug in it as 
> well (it is still a bit unclear how tcp variables behaved during my 
> scenario and I'll investigate further) but reduction in the transfer 
> rate is going to last longer than a short moment (which is used as 
> motivation in those FACK notes). In fact, if I just use RFC2581 like 
> setting w/o rate-halving (and experience the initial "pause" in sending), 
> the ACK clock to send out new data works very nicely beating rate halving 
> fair and square. For SACK/FACK it works much nicer because recovery is 
> finished much earlier and slow start recovers cwnd quickly.

I believe this is exactly the reason why Matt (CC'd) and Jamshid 
abandoned this line of work in the late 90's.  In my opinion, it's 
probably not such a bad idea to use cwnd/2 as the bound.  In some 
situations, the current rate-halving code will work better, but as you 
point out, in others the cwnd is lowered too much.


> ...Mind if I ask another similar one, any idea why prior_ssthresh is 
> smaller (3/4 of it) than cwnd used to be (see tcp_current_ssthresh)?

Not sure on that one.  I'm not aware of any publications this is based 
on.  Maybe Alexey knows?

   -John

  reply	other threads:[~2007-12-04 21:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-04 16:48 [PATCH net-2.6 0/3]: Three TCP fixes Ilpo Järvinen
2007-12-04 16:48 ` [PATCH 1/3] [TCP] FRTO: Use of existing funcs make code more obvious & robust Ilpo Järvinen
2007-12-04 16:48   ` [PATCH 2/3] [TCP]: Move prior_in_flight collect to more robust place Ilpo Järvinen
2007-12-04 16:48     ` [PATCH 3/3] [TCP]: NAGLE_PUSH seems to be a wrong way around Ilpo Järvinen
2007-12-05 10:26       ` David Miller
2007-12-05 11:18         ` Ilpo Järvinen
2007-12-05 11:33           ` David Miller
2007-12-05 10:21     ` [PATCH 2/3] [TCP]: Move prior_in_flight collect to more robust place David Miller
2007-12-05 10:21   ` [PATCH 1/3] [TCP] FRTO: Use of existing funcs make code more obvious & robust David Miller
2007-12-04 18:42 ` [PATCH net-2.6 0/3]: Three TCP fixes John Heffner
2007-12-04 21:10   ` Ilpo Järvinen
2007-12-04 21:17     ` John Heffner [this message]
2007-12-04 21:26       ` Ilpo Järvinen
2007-12-05 11:17         ` Alexey Kuznetsov
2007-12-05  2:13       ` Matt Mathis
2007-12-05 10:30   ` David Miller
2007-12-05 11:30     ` Ilpo Järvinen
2007-12-06  4:56       ` David Miller

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=4755C3E9.4090609@psc.edu \
    --to=jheffner@psc.edu \
    --cc=davem@davemloft.net \
    --cc=ilpo.jarvinen@helsinki.fi \
    --cc=mathis@psc.edu \
    --cc=netdev@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 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.