发送窗口有些问题。在rto期间发送窗口会保持在一个值，而不是变为1，不知是否有影响。
老师说的没错。把link-buffer从32改到33,只加了1个，就能让server数为3时的吞吐量从31变成931.
我用3个文件分别记录0,1,2这3个server的窗口数和已收到的数据量，以及实时显示当前累计传输的数据量。在out.ns的最后可以发现，
+ 1.205563 2 0 tcp 1500 ---A--- 0 2.0 1.0 178 1105
我查找包含“2.0 1.0 178”的，发现在第4860行，有
d 1.005114 0 1 tcp 1500 ------- 0 2.0 1.0 178 821
这个发生rto的包是有2发往1,即server 0 发往 client的。
然后我对这几个文件都查找在1.0051时的情况，发现
server 0：
1.0051999999999057 17.3941
1.0051999999999983: Server: 0, bytes: 243040
total bytes is : 585120
server 1：
1.0051999999999057 16.6887
1.0051999999999983: Server: 1, bytes: 235540
total bytes is : 585120
server 2：
1.0051999999999057 11.1404
1.0051999999999983: Server: 2, bytes: 106540
total bytes is : 585120
//////////////////////////////////////////////////////////
仔细研究下这里面的A事件（表征发生重传）。然后发现，RED里的server数为3时，trace里有A标志的条目真多。在ns manual的26.4最后看到，A代表CWR！
忽然意识到一个问题，我似乎忘记开启ECN了！看看当时dctcp patch里怎么做的！如果没开启ecn那肯定不会有效果的啊。
之前本来是打算先把dctcp实现了再加我的算法，所以默认的一些参数的开启没有考虑太多，比如ecn。
咦，是不是因为我没开启ecn，导致原本该打ecn的变成直接drop了？
我试着在incast.tcl里模仿dctcp example加了句set Agent/TCP ecn_ 1 ，但是还是没效果。
------------------------------------------------------------------------------
了解一下otcl与c++的变量的连接，从而在tcl脚本里得到c++里的变量值。比如red.cc里的某个值。
1.20
我怀疑red里既可以按一定概率丢包，也可以按一定概率打ecn。是不是应该专门设置一下才是打ecn，而未设置的时候就是丢包？而由于采用的是按一定概率丢包的机制，在各个流窗口尚小（7）的时候就开始丢了，导致丢掉一个窗口发送RTO。而droptail在丢包时窗口已经是16了，不容易丢完整个窗口，所以未发生rto。
查一下red ecn确认下什么时候打标记，什么时候丢包。以及看一下red.cc的程序。
《TCP and Explicit Congestion Notification》
In our simulations using RED gateways with ECN,the RED gateways set the ECN field in the packet header; in the simulations using RED gateways without ECN, the RED gateways drop the packet instead. In both variants of RED gateways, the gateway drops a packet when a packet arrives to a full queue.
确认一下是否是ecn没打开，导致原本该mark ECN 的成了drop？毕竟没看到flags里关于CE之类的位啊。
http://www.netlab.tkk.fi/opetus/s38180/s03/exercises/ex6/ex6.pdf
To activate ECN in ns2, one must set ecn_ property for Agent/TCP objects it is needed and also queues must have setbit_ true.
ns manual
setbit_ Set to "true" to mark packets by setting the congestion indication bit in packet headers rather than drop packets.
加了tcp_($i) set ecn_ 1后会有bug。
是不是需要设置下queue RED的参数之类的。比如 http://www.mathcs.emory.edu/~cheung/Courses/558/Syllabus/08-RED/RED.html
Queue/RED set q_weight_ 0.002
Queue/RED set thresh_ 10
Queue/RED set maxthresh_ 20
Queue/RED set setbit_ true
参考：http://blog.sina.com.cn/s/blog_858820890100s9yo.html
Queue/RED set thresh_ $queue_min
Queue/RED set maxthresh_ $queue_max
Queue/RED set q_weight_ $queue_weight
Queue/RED set setbit_ true
Queue/RED set gentle_ false
// ns2-first report presentation
Red queue marks messages rather than throws them away:
Queue/RED set setbit_ true : turning option on
$redq set setbit_ true : defining particular queue
Tcp agent have to support ecn option:
Agent/TCP set old_ecn_ 1 : turning option on
$tcpAgent set ecn_ 1 : defining particular agent
//
或者设置minthresh为3，max为6、15. 5,15?
或者设置Queue/RED set gentle_ true？
在使用red时，发生rto的是第2个server，即看s4_1.out
在使用droptail时，发生rto的是第1个server，即看s4_0.out
对比这两个文件的10211-10233行。发现它们的窗口增长略有不同。这是因为red在1.000599到1.000699之间已经丢了好几个包了。
我感觉是我的ecn设置还没有打开。不然为什么我把agent/tcp set ecn_ 1那一块给注释掉后吞吐量还没有变化？
但是矛盾的是我在red.cc里都改成return 0也不行。试试还有没有其他可以改的地方。
后来发现注释掉开头的agent/tcp set那一段还是有细微变化的。注释掉之前（即开启ECN时）吞吐量是42.42xxx，注释掉之后（未开启ECN）吞吐量是42.0409。
观察对比了red_4和droptail_4下的out.ns。它们在1-425行（1.000593）竟然是一模一样的，直到第426行red发生了drop，并开始持续drop直至发生RTO（此时由于时间早，red下各流窗口都较小，7左右，丢包有可能丢掉一整个窗口）。
而droptail直到764行（1.000843）才开始丢包，这时候它的窗口已经有16这么大了，所以虽然也丢了很多包但没导致RTO。
准备生成queue monitor来观察一下red queue到底是怎么回事。
http://www.mathcs.emory.edu/~cheung/Courses/558-old/Syllabus/90-NS/trace.html
e.g.
set file1 [open qm.out w]
set qmon [$ns monitor-queue $n2 $n3 $file1 0.1]
[$ns link $n2 $n3] queue-sample-timeout
终于通过queue monitor把red和droptail下实时的queue size分别给打印出来了。一对比果然发现了奇怪的事。同比较它们的out.ns一样，在发生第一个drop之前queue size的情况也是完全一致的。在发生drop以后开始不一样。我发现droptail的queue size有很大一块是集中在30多，这也是它的极限值。根据buffer设定的32,这是符合常理的。但是red的queue size就不太正常，它的queue size最多就能到10点多，就开始丢包了。应该是red里的什么机制导致的，需要看一下red.cc
之前怀疑是ecn没打开，但是在red.cc里修改后也没差别。
red.cc里：
double mark_p; /* when p < mark_p, mark chosen packets */
/* when p > mark_p, drop chosen packets */
int use_mark_p; /* use mark_p only for deciding when to drop, */
/* if queue is not full */
/* Set use_mark_p true and set mark_p to 2.0 */
/* to always mark instead of drop */
/* when queue is not full */
看看在$ns duplex-link <node1>... <qtype> <args> 是否需要针对RED专门设置下<args>？
看一下red.cc里的queue size是怎么传过去的，哪个变量表示的queue size。这个通过queue_monitor的trace函数也能找出是哪个变量。追踪一下这个变量是被谁赋值的，之间有没有被改动。也可以对比droptail.cc看一下。
15.1.22 noon：
在tcl/lib/ns-default.tcl里看到，在默认参数里，RED里是
Queue/RED set queue_in_bytes_ true
而 DropTail里是
Queue/DropTail set queue_in_bytes_ false
于是在incast.tcl里加上一句：Queue/RED set queue_in_bytes_ false
之后，RED的吞吐量上来了！至少是跟Droptail一个数量级了，而且在server数增多时还比DropTail要好！继续测试ing
在ns manual的P74发现：
bytes_ ：
Set to "true" to enable “byte-mode” RED, where the size of arriving packets affect the likelihood of marking
(dropping) packets.
queue-in-bytes_ ：
Set to "true" to measure the average queue size in bytes rather than packets. Enabling this option also
causes thresh_ and maxthresh_ to be automatically scaled by mean_pktsize_ (see below).