[EToSat] Hot Restart (was: Re: [iccrg] Agenda items for ICCRG meeting)

[Christian Huitema <[e-mail]>]

On 10/19/2020 12:02 PM, Jana Iyengar wrote:
> Hi all,
>
> We are meeting during IETF 109. If you have something you'd like to
> present, please send me a request by October 26th at the latest.

This is a late request, I would understand why it would not be accepted,
but here it goes. We have been discussed "hot restart" on the QUIC WG
list, but I think some of that discussion really belongs in ICCRG. The
idea is for nodes to remember the data rate, RTT or ssthresh observed in
previous connections, and use those parameters when starting new
connections. For example if using RENO, instead of going through
slow-start, the node could just set the ssthresh and RTT to the
remembered values, and "restart hot" by going directly into congestion
avoidance. Of course, this is a trade-off between performance and risk
of congestion. It needs to be discussed, and ICCRG looks like a good
place to have that discussion. Hence my request for a few minutes to
present the problem.

The proposal is largely motivated by satellite communications, which
combine high bandwidth and large RTT. Classic slow start ramps up by
doubling the congestion window every RTT. This looks fast, but still
requires a number of round trips --  log2(BDP/IW). For example, using
1500 bytes packets on a 1Gbps satellite link, it takes more than 7
seconds to ramp up from IW = 10 to the target CWIN of 50000 packets.
There is thus a push to "restart faster", which might be achieved by
reusing parameters from a previous connection.

The risk of congestion is obvious. The previous connection might have
achieved 1Gbps when it was the sole user of the satellite link, but by
the time the second connection starts there might be other users. Hot
restart at full bandwidth would create instant congestion, causing
queues and losses for the connections of these other users. There are
probably ways to mitigate that using less aggressive variations of "hot
restart". For example, in more cautious variants, the nodes could still
run slow start, but would set the initial congestion window to a
fraction of the remembered value, say one half or one quarter -- not so
hot a restart, but still much faster than starting from the default
initial window. We can imagine setting the fraction as a function of the
age of the previous measurement, but we don't have much guidelines there.

To me, it sounds like something that might interest this research group.
What do you think?

-- Christian Huitema