double check some results

steven's suggestion:
1. check cwnd convergence with a longer duration of the simulation (done. due to a script bug which grab cwnd_ and cwnd_cut_ into cwnd. Other results are all valid).
2. single flow to see what's the queue distribution
3. use c/n, instead of c, to recalculate the burst size.
4. measure the RTT loss rate for small flow and for large flow.

Yao's techniqe

Seems to be a powerful tool for bound the performance of random algorithm. Here is an introduction:
http://www.cs.pitt.edu/~kirk/cs2150/yao/yao.html

plan for the rest of this week

1. Try HSTCP/Scalable/BIC with High speed scenarios
2. Make clear the use of oprofile
3. finish the review of globecom paper

Add overhead on the processing time

I added uniformly distributed (over [0, 1ms]) processing time to each TCP source.
The unfairness is still there.

Here are some results:

4reno Result:

without overhead:

with overhead:



without overhead:

with overhead:

4newreno Result:

without overhead:

with overhead:



without overhead:

with overhead:

a summary of the pace vs non-paced issue

http://www.cs.caltech.edu/~weixl/projects/pacing/vsnonpacing.ppt

graph summary

1. split the figures in to two types: cwnd+seq and cut_event + cut_window_size
2. calcualte the loss rate for each scenario
3. draw the queue distribution and queue distribution for each packet train.

need to write a program to read queue.trace:
1. scanf("%c %lf %d %d %s %d %s %d %f %f %d %d", event, time, s, d, type, size, flags, flow, source, destination, seq, pktid), look at + - d events only.
2. calculate queue length; per packet loss rate for flow 1 or 2.
3. output one sample to per packet queue length; flow1's to per pakcet queue length or flow2's per flow 2 packet queue length.
4. find the last time the packet (with the same od pair) arrives. if the interval is smaller than (size+ack/c): take it as a burst. otherwise, flush the old record to sample and refresh the record.

plan for simulation with think-time and short flow

This should be my last effort to deal with Agg00. After that, I should turn to new variants.

1. Check each source TCP every second. to see if maxseq_==seqno_. if yes, let ftp to send more after a random think time

2. add a new check event at [$ns now]+1.

make clean can not completely clean NS2 objects

Here is an example:
I defined a TracedInt in tcp.h. Compiled, and runned.

Then I found I should define it as a TracedDouble. So I changed from TracedInt to TracedDouble.
The c++ part worked fine.

But it seems that the ns2 always output the traced variable as in int format. (This should be the problem of linking tclcl-1.16/tracedvar.cc with cpp...

I "make clean" but it does not help.

I think this is sth related to the tcl binding problem.... still not sure what happened yet...

I cannot re-link

add a traced variable in ns-2:

1. Add a TracedInt member in head file in cpp space
2. do whatever you need with the variable in cpp space.


3. ma in ns-2.28/tcl/lib/ns-default.tcl to define the variable in tcl space.

even ns2 version affects the pacing's results

After I changed from ns2.27 to ns2.28, the result of pacing changed, too.
Here are the new results (with 2.28) for competition of paced and non-paced tcp:
label with 1 is for pacing tcp and label with 2 is for non-paced tcp.

win is the aggregate congestion window
cut is the aggregate # of congestion reduction (# of loss event rate)
seq is the aggregate maxseq # (aggregate throughput)

Another strange thing to be make clear: the non-paced flows suffer significantly more cwnd cut than paced flows. but they still achieve higher throughput. Why?

Reno:


New Reno:


FACK:


In comparison, here is the corresponding results with ns2.27:
Reno:


NewReno:


FACK:

ns installation on new machines

Finish installing ns to on a new xeon*2 machine. from tomorrow, i can use this fast machine to replace the PIII 750 cs machine. cool~

To have an easy installation with all-in-one package, i'd suggest:
1. a linux system with Xwin and X-wind-development (all the X headers)
2. the up-to-date ns-2 package.

Don't bother with the tcl error or tk error if you have a out-of-date tcl or tk, or tclcl or otcl... download the latest package and install them -- this is the quickest way to solve the problem, i think.

summary of Agg00 results -- long flow

http://www.cs.caltech.edu/~weixl/projects/pacing/agg00/summary.ppt

Next step:
1. short flow (latency)
2. BIC
3. New pacing with relaxed rate control

reproducing Agg00's results

summary of Agg00's experiments:

parameters:

• n: number of flows;
  
• c: bottleneck bandwidth
• r: ratio of paced TCP
• b: bottleneck buffer size

static parameters:

• delay of the side link: 5ms
• delay of the bottlenck: 40ms
• side link bandwidth: 4c
• MSS: 576 bytes
• TCP Variant: TCP Reno without delay ack

Experiments:
1. n=1; bdp=10, 20, 60, 120, 160, 220 pkt; c= bdp/50; b=1/4*bdp; r =0% or 100%
2. n=50; RTT=100ms; bandwidth=57Mbps; buffersize: 312pkt; BDP: 1250; r = 0% or 100%
3. n=50; RTT=100ms and 280ms (50%); bandwidth=57Mbps; buffersize: 312pkt; BDP: 1250; r = 0% or 100%

4. rtt:100ms; flow# :20; buffer size: 1/4BDP; bottleneck 25Mbps; flow size: 10, 100,1000, 10E4, 10E5, inter-flow time: exp distributed with mean of 1sec. r=0 or 100%

5: flow size: 300 pkts; rtt: 100ms; flow#: 20; buffer size: 1/4BDP; bottleneck 25Mbps r= 0, 10%...100%

preliminary result of paced vs unpaced tcp

one paced tcp vs one unpaced tcp.
Topology (script):

tcp1 -> n0 -> n2 -> n3 -> sink1 (unpaced TCP)
tcp2 -> n1 -> n2 -> n3 -> sink2 (paced TCP)

n0->n2, n1->n2: 2Mb 10ms
n2->n3: 1Mb 20ms

The effect is actually different for different TCP variants. In general, as the length of the flow is large enough, paced TCP is better.



See the following details:

Flow 2 is the paced flow and flow 1 is the unpaced flow.

1. Reno:


Reno vs Reno



2. NewReno:


NewReno vs NewReno




3. FACK:


Fack vs Fack





4. Plain TCP



Tahoe vs Tahoe

Plan for the next step.

Finally, per packet pacing is implemented.
The next three steps:
1. Reproduce CERN experiment in simulation
2. Reproduce Agg00's result
3. Check BIC TCP with 1 and 2.

Tonight: try 1. and study Pei's question on per RTT loss reaction. Tomorrow: read papers Pei listed.