Currently only basic congestion control is done when retransmitting packets. No congestion control is performed when sending new packets.
The problem is that the application is "in control", as it pushes/pulls data to/from the protocol. The protocol should not delay sending of packets due to highly congested network; It should inform the application about the current status of network congestion and let the application decide how much to throttle amount of data / rate of data that is being send. (e.g. Protocol.getCongestionFactor(): double -> if its greater than 1, application could send more data -> if its less than 1, application could send less data).
Investigate existing congestion control algorithms - look at their characteristics
preferably use the ones which do not send extra metadata about network congestion; preferably use the ones that consider RTT, RTT variance, (estimated) packet loss, the form of the lastTransmissionAcks field and the offset from sender side transmissionId and received transmissionAck (as well as the history of this offset - mean/deviation); preferably use the ones which are a bit more aggressive:
Notes on form of the lastTransmissionAcks vector field:
vector v
v[i] = {0, 1} ... 0 = acked, 1= notAcked
i € {0, n}, 0 is most recent, n is oldest transmissionAck:
- weightingFactor = #{i: v[i] = 0} / n ... the more notAcked, the greater the factor
- sum_1 = sum(i: 0..n) v[i] * log(n/i) <=> v[i] != v[i+1] .... most recent not acked carry most weight
- sum_2 = sum(i: 0..n) v[i] * log(n/i) * v[i+1] * log(n/i) <=> v[i] == v[i+1] ... the greater a continuous gap of not acked, the multiplicative more weight it has
- score = (sum_1 + sum_2) * weightingFactor
Investigate fast retransmit -> resend packets that are missing in lastAcks field: this could work if we send at @ 10 Hz (every 100ms), but does not make sense if we send @ 120 Hz (every 9 ms), as due to jitter many packets get send before the out of order packet arrives -> ADDED
Currently only basic congestion control is done when retransmitting packets. No congestion control is performed when sending new packets.
The problem is that the application is "in control", as it pushes/pulls data to/from the protocol. The protocol should not delay sending of packets due to highly congested network; It should inform the application about the current status of network congestion and let the application decide how much to throttle amount of data / rate of data that is being send. (e.g.
Protocol.getCongestionFactor(): double-> if its greater than1, application could send more data -> if its less than1, application could send less data).Investigate existing congestion control algorithms - look at their characteristics
preferably use the ones which do not send extra metadata about network congestion; preferably use the ones that consider RTT, RTT variance, (estimated) packet loss, the form of the
lastTransmissionAcksfield and the offset from sender sidetransmissionIdand receivedtransmissionAck(as well as the history of this offset - mean/deviation); preferably use the ones which are a bit more aggressive:Notes on form of the
lastTransmissionAcksvector field:vector v
v[i] = {0, 1} ... 0 = acked, 1= notAcked
i € {0, n}, 0 is most recent, n is oldest
transmissionAck:Investigate fast retransmit -> resend packets that are missing in
lastAcksfield: this could work if we send at @ 10 Hz (every 100ms), but does not make sense if we send @ 120 Hz (every 9 ms), as due to jitter many packets get send before the out of order packet arrives -> ADDED