Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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
Member

@larseggert larseggert commented Aug 31, 2021

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
Member Author

@larseggert larseggert commented Sep 16, 2021

@lisongxu, any update?

@lisongxu
Copy link
Collaborator

@lisongxu lisongxu commented Sep 17, 2021

@larseggert sorry for the delay, will catch up soon

@lisongxu
Copy link
Collaborator

@lisongxu lisongxu commented Sep 28, 2021

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
Member Author

@larseggert larseggert commented Oct 11, 2021

@markkukojo, please comment on the above?

@larseggert
Copy link
Member Author

@larseggert larseggert commented Nov 1, 2021

No response from @markkukojo in three weeks, closing.

@larseggert larseggert closed this Nov 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants