When I conducted an attack experiment using bmv2, the TCP congestion control seemed to fail

[cjb20001108]

When I was conducting attack experiments using the bmv2 switch and Mininet, I noticed that the TCP congestion control seemed to not work properly.

With only Mininet and an OpenFlow switch, the TCP congestion control functioned perfectly, and the graph was very standard, showing a clear slow recovery process of the congestion window. However, when using the bmv2 switch, after the background TCP traffic was attacked, the congestion window appeared to recover instantly.

I set a bandwidth of 10M and a link queue of 200 in the Mininet link. Figure 1 shows the instant recovery with bmv2, while Figure 2 shows the normal (recovery) situation. I hope someone can help me with this issue.

By observing the sender’s cwnd (congestion window), I found that it would only drop from over 100 to 70 or 80 during an attack, and then recover instantly, failing to achieve TCP congestion control.

When the attack traffic congests the bandwidth, packet loss does occur.I am using simple_switch_grpc.

[ederollora2]

Hi @cjb20001108 ,

@cjb20001108

I set a bandwidth of 10M and a link queue of 200 in the Mininet link. Figure 1 shows the instant recovery with bmv2, while Figure 2 shows the normal (recovery) situation. I hope someone can help me with this issue.

As far as I understand, BMv2 is mainly for debugging purposes (not so sure what @andyfingerhut said) . So you cannot directly compare an OpenFlow switch with the simple_switch_grpc. However, you can say that although they cannot be compared directly, you analyzed both separately.

Cheers