multipath-tcp / mptcp

⚠️⚠️⚠️ Deprecated 🚫 Out-of-tree Linux Kernel implementation of MultiPath TCP. 👉 Use https://github.com/multipath-tcp/mptcp_net-next repo instead ⚠️⚠️⚠️
https://github.com/multipath-tcp/mptcp_net-next
Other
888 stars 336 forks source link

Bandwidth-Delay Product Calculation #311

Closed FiratA closed 5 years ago

FiratA commented 5 years ago

Hello,

do you guys know how to calculate the BDP in case of packet loss? Because packet loss, does increase the latency (RTT) and then the whole calculation is not valid anymore. Usually the RTT is in ms and the values are varying a lot. Is there any other way to solve it?

Thanks in advance.

dweb32 commented 5 years ago

Hello @FiratA,

there exists no way for solving this exactly, but there are some ways to estimate it.

Basically, when we talk about RTT we typically refer to the smothed round-trip time sRTT [ms] that takes the highly variable RTTs into account. Have a look at Karn's algorithm that is used in TCP:

Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 87

The other part of the estimation is the loss rate p [%]. For a single TCP connection, you can model the probability P that a packet arrives at k transmission as simple Bernoulli experiment where (k-1) transmissions failed before: P[k] = p^(k-1) * (1-p)

Expanding the experiment into infinity you obtain a mean expectation of 1/(1-p) transmissions until the data is successfully received. Hence, your overall estimate for a BDP that takes packet loss into account can be expressed by: BDP = bandwidth [bit/s] sRTT [s] 1 /(1-p)

When using MPTCP, the hole thing becomes more difficult. Depending on the scheduling strategy, a data segment can be sent on different subflows. Think of the situation where a packet is lost on subflow 1 and is reinjected into subflow 2... that's, the point were it gets easier to just estimate the upper bound of the BDP and take the sum of all paths. Or if you use the redundant scheduler, the total BDP should be more or less equal to the BDP of the best single-path.

The are experimental schedulers that try to be more efficient in lossy networks using the same calculation from above, e.g. the LAMPS scheduler, but until today I was not able to reproduce any beneficial result that is claimed in this publication:

Dong, E., Xu, M., Fu, X., & Cao, Y. (2017, October). LAMPS: A Loss Aware Scheduler for Multipath TCP over Highly Lossy Networks. In 2017 IEEE 42nd Conference on Local Computer Networks (LCN) (pp. 1-9). IEEE.

I hope I was able to point you into the right direction.

matttbe commented 5 years ago

@s6dlwebe thank you for this nice answer. @FiratA I hope you don't mind if I close this ticket!