From: Nivedita Singhvi <niv@us.ibm.com>
To: Injong Rhee <rhee@eos.ncsu.edu>
Cc: "'David S. Miller'" <davem@redhat.com>,
"'Stephen Hemminger'" <shemminger@osdl.org>,
netdev@oss.sgi.com, rhee@ncsu.edu, lxu2@ncsu.edu
Subject: Re: [RFC] TCP burst control
Date: Tue, 06 Jul 2004 19:20:59 -0700 [thread overview]
Message-ID: <40EB5E0B.1030407@us.ibm.com> (raw)
In-Reply-To: <200407070009.i6709wiA026673@ms-smtp-03-eri0.southeast.rr.com>
Injong Rhee wrote:
> Hi David and Stephen,
>
> We tested this rate halving. In fact, rate having in fact degrades the
> performance quite a bit. We can send you more information about it. Our test
> indicates that this feature introduces many timeouts (because of bursts),
> and also cause unnecessary cwnd backoff to reduce the transmission
> unjustifiably low -- so there are many (I will repeat, many) window and
> transmission oscillations during packet losses. We fix this problem
Could you point me to a paper or summary of your info?
> completely using our own special burst control. It is very simple and easy
> technique to implement. If you need some data to back up our claims, I will
> send you more. Once we implemented our burst control, we don't have any
> timeouts and not much fluctuation other than congestion control related.
> Currently with rate having, current Linux tcp stack is full of hacks that in
> fact, hurt the performance of linux tcp (sorry to say this). Our burst
> control, in fact, simplifies a lot of that and makes sure cwnd to follow
> very closely to whatever congestion control algorithm is intended it to
> behave. The Linux Reno burst control in fact interferes with the original
> congestion control (in fact, it tries to do its own), and its performance is
> very hard to predict.
Can you characterize the workload/traffic/error rate that each
would be best suited for?
thanks,
Nivedita
next prev parent reply other threads:[~2004-07-07 2:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-06 22:58 [RFC] TCP burst control Stephen Hemminger
2004-07-06 23:04 ` David S. Miller
2004-07-07 0:09 ` Injong Rhee
2004-07-07 0:29 ` David S. Miller
2004-07-07 5:46 ` Injong Rhee
2004-07-07 5:49 ` Injong Rhee
2004-07-07 15:31 ` Matt Mathis
2004-07-09 15:36 ` Injong Rhee
2004-07-15 0:11 ` Weiguang Shi
2004-07-07 2:20 ` Nivedita Singhvi [this message]
2004-07-28 9:48 ` Xiaoliang (David) Wei
2004-07-28 13:45 ` Lisong Xu
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=40EB5E0B.1030407@us.ibm.com \
--to=niv@us.ibm.com \
--cc=davem@redhat.com \
--cc=lxu2@ncsu.edu \
--cc=netdev@oss.sgi.com \
--cc=rhee@eos.ncsu.edu \
--cc=rhee@ncsu.edu \
--cc=shemminger@osdl.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.