Evaluate multipath BBR congestion control on ns3

 The authors in [1,2] propose a couple BBR congestion control algorithm for multipath transmission.
  A dumbbell topology is built to evaluate whether the multipath BBR session can behave friendly to single BBR session. You know, one of the goal of multipath congestion conrol is “do not harm”[3]:

Goal 2 (Do no harm) A multipath flow should not take up more capacity from any of the resources shared by its different paths than if it were a single flow using only one of these paths. This guarantees it will not unduly harm other flows.

/** Network topology
 *
 *    100Mb/s, 20ms                            100Mb/s, 20ms
 * n0--------------|                    |---------------n4
 *                 |   5Mbps/s, 10ms    |
 *                 n2------------------n3
 *  100Mb/s, 20ms  |                    |    100Mb/s, 20ms
 * n1--------------|                    |---------------n5
 *
 *
 */
n0--L0--n2--L1--n3--L2--n4
n1--L3--n2--L1--n3--L4--n5

 Parameters on each link:

typedef struct
{
uint64_t bps;// bandiwidth
uint32_t msDelay;//propagation delay
uint32_t msQdelay;	//maxmium buffer length bps*msQdelay
}link_config_t;

 Four flows are tested. And flow1 and flow4 are two subflows of a multipath session. flow2 and flow3 take origin BBR for rate control. flow1 and flow2 take route(n0->n4). flow3 and flow4 take route(n1->n5).

Test on two paths with same propagation delay

 Link configuration on above dumbbell topology

link_config_t p4pLinks[]={
[0]={100*1000000,20,200},
[1]={5*1000000,10,200},
[2]={100*1000000,20,200},
[3]={100*1000000,20,200},
[4]={100*1000000,20,200},
};

When flow1 and flow4 follow the congestion control rule of couple BBR.

 The sending rate of each flow:

 Packets received rate, here mp denotes the total throughput of the multipath session:

When flow1 and flow4 perform congestion control seperately.

 The sending rate of each flow:

 Packets received rate(calculated at every 5 seconds):

Comments

 The couple BBR session indeed behaves friendly to single path BBR.

Test on two paths with different propagation delay

 Link configuration on above dumbbell topology

link_config_t p4pLinks4[]={
[0]={100*1000000,10,200},
[1]={8*1000000,10,200},
[2]={100*1000000,10,200},
[3]={100*1000000,20,200},
[4]={100*1000000,20,200},
};

When flow1 and flow4 follow the congestion control rule of couple BBR.

 The sending rate of each flow:

 Packets received rate:

  BBR has a known issue that it flavors towards flows with longer rtt. That’s the reason that flow3 can achieve higher rate than flow2.

When flow1 and flow4 perform congestion control seperately.

 The sending rate of each flow:

 Packets received rate:

[1] Measurement and Redesign of BBR-based MPTCP
[2] Leveraging Coupled BBR and Adaptive Packet Scheduling to Boost MPTCP
[3] Coupled Congestion Control for Multipath Transport Protocols
[4] mptcp耦合式拥塞控制
[5] C-MPBBR