Re: [tcpm] I-D Action:draft-nishida-newreno-modification-02.txt

[Yoshifumi Nishida <[e-mail]>]

Hi People, I hope it is the right time for this..

I submitted the new version for draft-nishida-newreno-modification today.
If someone could give me any feedback, I would be grateful very much.

This draft describes the issue in Newreno. The problem I mentioned in the draft is
if the following two conditions are satisfied, the tcp connection will encounter 
performance degradation.

  1: receiver uses delayed ack
  2: flightsize is 0 when tcp exits fast recovery

I believe 1 is true for most of all implementations. The question is if 2 is a 
very corner case and can be negligible. I feel one of the reason why I hardly 
got any response so far is that people think 2 is negligble.

So, I would like to present a simulation result here to claim that this might
not be negligble. I used ns-2.34 and created 2 TCP nodes (sender and receiver) 
and created packet loss on the 10Mbps link between them. The tcp sender sent 
100,000  packets to the receiver. The below table shows the number of events 
where flightsize becomes 0 after fast recovery.

                 PLR=0.01   PLR=0.02   PLR=0.03   PLR=0.04   PLR=0.05   PLR=0.06
 # of events       108        333        687       1140       1537       1916

>From this result, if PLR exceeds 0.04, the ratio of this event exceeds 1% of
packet transmissin. This affects throughput drastically as shown in the below
table. "newreno" is the current algorithm in RFC3782 and "proposed" is the 
proposed algorithm in the draft.

                            throughput (kbps)          

            PLR=0.01   PLR=0.02   PLR=0.03   PLR=0.04   PLR=0.05   PLR=0.06  
 newreno     825.57     451.96     284.25     190.13     137.99     107.05    
 proposed   1006.64     671.86     470.39     344.28     248.71     193.30    


>From these results, I personally think this draft is worth being discussed.
Again, If someone could give me any feedback, I would be grateful very much.
I'm happy to discuss this at Anaheim if someone wants.

Please check detailed simulation configurations and results in the draft.

Thanks,
--
Yoshifumi Nishida
[e-mail]



From: [e-mail]
Subject: I-D Action:draft-nishida-newreno-modification-02.txt 
Date: Tue,  2 Mar 2010 02:00:02 -0800 (PST)
Message-ID: <[e-mail]>

 > A New Internet-Draft is available from the on-line Internet-Drafts directories.
 > 
 > 	Title           : NewReno Modification for Smooth Recovery After Fast Retransmission
 > 	Author(s)       : Y. Nishida
 > 	Filename        : draft-nishida-newreno-modification-02.txt
 > 	Pages           : 16
 > 	Date            : 2010-03-02
 > 
 > This memo describes a feeble point in Fast Recovery algorithm in
 > NewReno defined in RFC3782 and proposes a simple modification to
 > solve the problem.
 > 
 > A URL for this Internet-Draft is:
 > http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-02.txt
 > 
 > Internet-Drafts are also available by anonymous FTP at:
 > ftp://ftp.ietf.org/internet-drafts/
 > 
 > Below is the data which will enable a MIME compliant mail reader
 > implementation to automatically retrieve the ASCII version of the
 > Internet-Draft.