Re: [RFC] cubic: backoff after slow start

2007-08-07 Thread 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]>; &qu

Re: 2.6.20.7 TCP cubic (and bic) initial slow start way too slow?

2007-05-10 Thread Injong Rhee
Thu, 10 May 2007 13:35:22 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: From: [EMAIL PROTECTED] Date: Thu, 10 May 2007 14:39:25 -0400 (EDT) > > Bill, > Could you test with the lastest version of CUBIC? this is not the > latest > version of it you tested. Rhee-sangsang-

Re: 2.6.20.7 TCP cubic (and bic) initial slow start way too slow?

2007-05-10 Thread rhee
Bill, Could you test with the lastest version of CUBIC? this is not the latest version of it you tested. Injong > As a followup, I ran a somewhat interesting test. I increased the > requested socket buffer size to 100 MB, which is sufficient to > overstress the capabilities of the netem delay em

Re: [patch 3/3] tcp: remove experimental variants from default list

2007-02-13 Thread Injong Rhee
ation. The version that D. Leith has tested is a version that fixes the earlier bug. Note that having bugs in the implementation does not warrant attacks on the algorithm itself. Some "weakness" of CUBIC.. please read my rebuttal on that paper in my website: http://www.csc.ncsu.edu/faculty/

Re: TCP congestion graphs

2006-10-25 Thread Injong Rhee
Not sure why the slow start for cubic is slower than the others. We will check on this. - Original Message - From: "Stephen Hemminger" <[EMAIL PROTECTED]> To: "Douglas Leith" <[EMAIL PROTECTED]>; "Sangtae Ha" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, October 25, 2006 2:02 PM Subject: TC

Stability of various TCP protocols [CUBIC, BIC, HTCP, HSTCP, STCP]

2006-09-28 Thread Injong Rhee
http://netsrv.csc.ncsu.edu/convex-ordering/ If you need our report on theoretical results, we can e-mail you the report. Injong Rhee - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://

Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc

2006-09-28 Thread Injong Rhee
t;[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Douglas Leith" <[EMAIL PROTECTED]>; ; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Injong Rhee" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, September 27, 2006 7:20 PM Subject:

Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc

2006-09-23 Thread Injong Rhee
confirmed inthe FAST journal paper [ http://netlab.caltech.edu/publications/FAST-ToN-final-060209-2007.pdf -- please look at Section IV.B and C. But your results show really bad RTT fairness.] Best regards, Injong --- Injong Rhee NCSU On Sep 22, 2006, at 10:22 AM, Douglas Leith wrote: For thos

Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc

2006-09-23 Thread rhee
Doug Leith wrote- > I suggest you take a closer look Injong - there is a whole page of data > from tests covering a wide range of levels of background traffic. These > results are all new, and significantly strengthen the conclusions I > think, as is the expanded explanatory discussion of the

RE: tcp_highspeed: bad performance?

2006-03-16 Thread Injong Rhee
Daniele, Which version of linux are you testing with? We have test results of linux high speed TCP options in http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/asteppaper.htm > -Original Message- > From: [EMAIL PROTECTED] [mailto:netdev- > [EMAIL PROTECTED] On Behalf Of Daniele

RE: [e2e] FW: Performance evaluation of high speed TCPs

2006-02-03 Thread rhee
Let's get off this e2e list for this discussion. It is really unnecessary to use this list for this discussion. I don't understand why you keep sending your email to this list even though we are seating next to each other in the same conference. Isn't this amusing or abusing of this mailing list?

RE: [e2e] FW: Performance evaluation of high speed TCPs

2006-02-02 Thread rhee
Sure. Your comments about running the buggy implementation are well taken. That is why this type of reporting is helpful and we are committed to keep this effort. Just that it takes time to run the tests, and before we run a new set of tests, we have to do some batch of patches to reduce our effor

Re: [e2e] FW: Performance evaluation of high speed TCPs

2006-02-02 Thread rhee
Doug, Sorry that we are not THAT real time in updating the report :-) Seriously, we can't run the tests for every fix and bug report. But we are aware of your new patch posted last week on the e2e list and indeed applied it to our testing platform for retesting.Now one test case is done (thanks to

RE: SACK performance improvements - technical report and updated 2.6.6 patches

2005-12-20 Thread Injong Rhee
Ditto. I remember we had some discussion on this sometime back in the netdev mailing list (Baruch was part of the discussion). > -Original Message- > From: David S. Miller [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 20, 2005 4:09 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED];

RE: SACK performance improvements - technical report and updated 2.6.6 patches

2005-12-19 Thread Injong Rhee
I wonder the same. I wonder how this new patch by the HTCP folks improves what we provided for the 2.6.x (which is currently incorporated in the latest linux version). My recollection says that this HTCP patch periodically crashes the system very often -- so we could not run the comparison. BTW, th