Intra Protocol Fairness -- Two Rapid Flows

1. Description

Machines running rapid flows: one rapid flow from smithfd-linux1 to smithfd-linux2 (flow1), another from smithfd-rapid1 to smithfd-rapid2 (flow2)
Rapid Version: rapid_v0.9
Network Paths: the routed path in netlab
TCP Configuration: All default
RTT: For certain experiments, use the per-connection-delay module to add 10ms or 30ms delay to the rapid flow if needed.
List of Experiments:
  • two cubic/rapid flow start at the same time with default round trip time(about 0.1ms), and the two flows are from different pairs of machines
  • two cubic/rapid flow start at the same time with default round trip time(a bout 0.1ms), and the two flows are from the same pair of machine
  • two cubic/rapid flow start at the same time with 10ms RTT, and the two flows are from different pairs of machines
  • two cubic/rapid flow start at the same time with 30ms RTT, and the two flows are from different pairs of machines
  • two rapid flow with 10ms RTT, and flow1 starts 10s before flow2 starts, and the two flows are from different pairs of machines
  • two rapid flow with 30ms RTT, and flow1 starts 10s before flow2 starts, and the two flows are from different pairs of machines

    2. Experimental Results:

  • Two rapid/cubic flows start at the same time with no delay on the router In the plots below, the red line represents flow1 from linux1 to linux2; the blue line represents flow2 from rapid1 to rapid2.
  • When there are two cubic flows:

  • When there are two rapid flows from different pairs of machines

  • When two rapid flows are from the same pair of machines

                                            flow1           flow2
    cubic                                   442Mbps  	499Mbps
    rapid from different machine pairs      736Mbps         2.84Mbps
    rapid from the same machine pairs       461Mbps         459Mbps
    
  • Two rapid/cubic flosw start at the same time with 10ms RTT
    		flow1-10ms		flow2-10ms
    cubic		206Mbps			198Mbps
    rapid-nolog	827Mbps			9.36Mbps
    
  • Two rapid/cubic flows start at the same time with 30ms RTT
                    flow1           flow2
    cubic           154Mbps         199Mbps
    rapid-nolog     86.5Mbps        84.9Mbps
    
  • Two rapid flows with 10ms RTT, flow1 starts first:

  • Two rapid flows with 30ms RTT, flow1 starts first:

    3. Conclusion:

  • For rapid flows from the same machine, the flows achieve comparable fair share because of the scheduling fairness od Qdisc module on one machine. Thus flows from different pair of machines reflect the properties of Rapid. And in the future experiments and discussions, we only consider flows from different pairs of machines.
  • For the case when RTT is default or 10ms, one rapid flow grasps the whole bandwidth however another fails to get fair share.
  • The reason for the phenomenon is that when two flows coexist, one flow fails to recover from retransmission state.
    An additional experiment was done which recorded the AB_est for each probe stream and the time that AB_est was computed. The throughput is as follows:

    The AB_est plots in terms of time is:

    So for flow2(the blue line) from rapid1 to rapid2, it created no probe streams during 2 to 20s because the TCP state during that time is TCP_CA_Recovery or TCP_CA_Loss.