TCP Divacks for Hand-overs
Divacks can be used to ramp-up the
cwnd for a TCP flow after a vertical handover.
When vertical handovers (or even horizontal handovers between networks with different levels of congestion) occur, the TCP rate may be adjusted. Right after the handover, the value of TCP's
cwnd is adapted to the previous network's capacity. This is if we are using a Freeze-TCP like proposal.
In our specific case, the TCP client shares an 802.11 connection. We know that this kind of connection limits the over-increase of the
cwnd when using divacks. However, after the blackout of the connection (because of the handover), the client can increase the congestion window faster if a burst of divacks is sent. The burst of divacks after the handovers has many advantages. First, the total number of divacks can be calculate in advance in order to ramp-up faster till the recently calculated capacity of the network. Second, the total-burst of divacks can have paced micro-burst of divacks so as not to congest the network in a over reaction. Moreover, this method can be adjusted and used in presence of network congestion.
To have feedback about the new network capacity, at least one new RTT has to elapse. It may then take several new RTTs for the congestion control state to update to the actual
cwnd the new network can support.
Considering mobile TCP receivers, it may be possible, using ACK division techniques, to ramp-up the remote server to ramp up its
cwnd and occupy the network more quickly.
Further attention may need to be paid to the possibility of ramping down the
cwnd without causing too much congestion on the new network if its capacity is not as large as the previous one. A work-around could be setting the
rwnd at the receiver to the desired value which, if smaller than the sender's
cwnd, will limit the throughput. An interesting solution may be to apply an AIMD algorithm on the receiver, and compute a
rcwnd which would be sent in place of the normal
wnd until it eventually becomes larger than the latter. Question: How would the sender update its local
cwnd during periods of receiver-controlled CC?