Skip to content
This repository has been archived by the owner on Aug 28, 2023. It is now read-only.

Sec 5.1 #92

Closed
larseggert opened this issue Aug 31, 2021 · 5 comments
Closed

Sec 5.1 #92

larseggert opened this issue Aug 31, 2021 · 5 comments
Assignees

Comments

@larseggert
Copy link
Contributor

Markku Kojo said:

Sec 5.1

In this subsection, one should show the impact of CUBIC when competing with AIMD TCP. The numbers in tables are derived from
analytical models that give average window size with fixed random loss probabilities and unlimited bandwidth. That is not the same as when flows are combeting in the same congested bottleneck that builds a queue.
Loss probabilities for different flows are likely to be different especially at lower levels of statistical multiplexing.

The first para of sec 5.1 does not sound like true. Simply looking at the original CUBIC paper [HRX08] reveals that CUBIC dominates AIMD TCP (SACK TCP) in the regions where SACK TCP alone is able to fully utilize the available bandwidth (Figure 10 c up until 200 Mbps, and to some extent in Fig 10 a with 40 ms delay). And ín all cases where SACK TCP alone is not able to utilize all available b/w, CUBIC steals multiple times more b/w from SACK TCP than what SACK TCP is not able to utilize. Figures 5 and 6 tell the same story. Has something changed and/or is there possibly data that provides alternative evidence.

In addition, the recommended value for constant C and the two alternative values presented in the draft are the same as in the original paper. It would be interesting to see if there has been any experimentation with different values and what might be the outcome?

@lisongxu lisongxu self-assigned this Sep 1, 2021
@larseggert
Copy link
Contributor Author

@lisongxu, any update?

@lisongxu
Copy link
Contributor

@larseggert sorry for the delay, will catch up soon

@lisongxu
Copy link
Contributor

Thanks, @markkukojo

You are right that the analytical model "gives average window size with fixed random loss probabilities and unlimited bandwidth." This demonstrates to some extent the AIMD friendliness (now referred to as Reno Friendliness in the document).

The original Cubic paper [HRX08] shows the experiment results when Cubic is competing with AIMD/Sack. Figure 10 shows that Cubic is friendly to Sack in low bandwidth or low RTT networks (although not exactly fair share). For example, in Fig 10(a), bandwidth=400Mbps, RTT=10 or 20ms; also in in Fig 10(b), bandwidth=10 -- 400 Mbps, RTT=10ms; Cubic is friendly to AIMD/Sack.

@larseggert
Copy link
Contributor Author

@markkukojo, please comment on the above?

@larseggert
Copy link
Contributor Author

No response from @markkukojo in three weeks, closing.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants