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

From: Carsten Bormann <[email-masked]>
Date: Sun, 1 Nov 2020 18:06:57 +0100

If the Internet had something like DSCP, packets that use speculative assumptions about the network status could be sent with a “discard me first” class.

Grüße, Carsten

> On 2020-10-31, at 19:38, Christian Huitema <[email-masked]> wrote:
> 
> 
> 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
> 
> 
> _______________________________________________
> EToSat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/etosat

---

From: Michael Welzl <[email-masked]>
Date: Mon, 2 Nov 2020 12:36:14 +0100

Hi Christian,

I’m answering below, as a co-author of 2140bis:

> On Oct 31, 2020, at 8:50 PM, Christian Huitema <[email-masked]> wrote:
> 
> 
> On 10/31/2020 11:51 AM, Michael Tuexen wrote:
>>> On 31. Oct 2020, at 19:38, Christian Huitema <[email-masked]> wrote:
>>> 
>>> 
>> How does this relate to
>> https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-05
> 
> It certainly does, to a degree. Draft-2140bis is very much centered on
> implementing TCP in the kernel, we would need to generalize to
> implementations of QUIC in user space. Also, much of the problem is
> related to choice of initial window, which is only addressed in an
> appendix to draft-2140bis. The algorithm in that appendix is very
> conservative, e.g., "An implementation MUST increase [the IW] by no more
> than 2 MSS per evaluation interval". This would not solve the practical
> problem with satellite links.
> 
> Also, draft-2140bis is very much solution oriented, prescribing
> algorithms. To convince the various implementers of QUIC, it would
> probably be more effective to provide supporting data, such as
> experience of correlation or not between network parameters over time.

We would have liked to be a bit more “adventurous” in terms of re-using some connection parameters, but encountered some resistance that was at least partially based on documented measurements.
For example, reference [Hu12] in our document ( Hurtig, P., Brunstrom, A., "Enhanced metric caching for short TCP flows," 2012 IEEE International Conference on Communications (ICC), Ottawa, ON, 2012, pp. 1209-1213.  ) suggests that re-using ssthresh is often not recommendable.

> If the Internet had something like DSCP, packets that use speculative assumptions about the network status could be sent with a “discard me first” class.

I suspect that the LBE DSCP (which IMO could be used for this) will have the same deployment problem as many other Internet mechanisms: no support in routers because no end systems use it, no usage by end systems because routers don’t support it … and it all gets stuck.  So, why not make a start, and be more adventurous, combined with setting the LBE DSCP?
I don’t know what prompted Carsten to write “If the Internet had something like DSCP”, though.

Cheers,
Michael

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 2 Nov 2020 14:13:53 +0100

Hi Michael,

> I suspect that the LBE DSCP (which IMO could be used for this) will have the same deployment problem as many other Internet mechanisms: no support in routers because no end systems use it, no usage…

You probably mean Lower-Effort LE PHB (RFC 8622). The nice thing about
this one is that global deployment won't hurt the providers as
it does no harm and requires no complex configuration (no traffic
conditioning necessary). So rolling out the LE PHB provides mainly
benefits, but requires at least an available separate queue. Using
two different PHBs within a micro flow (here transport connection)
will probably lead to massive packet reordering, but if the transport
protocol is able to cope with it, it may be viable.

Regards
 Roland

---

From: Michael Welzl <[email-masked]>
Date: Mon, 2 Nov 2020 15:22:21 +0100

> On Nov 2, 2020, at 2:13 PM, Bless, Roland (TM) <[email-masked]> wrote:
> 
> Hi Michael,
> 
> You probably mean Lower-Effort LE PHB (RFC 8622).

Yes. Sorry for the wrong name.

> The nice thing about

Right. Very much something worth playing around with, IMO.  (this is on an IRTF mailing list after all)

Cheers,
Michael

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 9 Nov 2020 20:59:49 -0800

Hi Szilveszter,

Apologies for taking a while to respond -- it's been a couple of difficult
weeks. Are you still interested? I'd be happy to give you 20 minutes
(include Q&A). In general, I think it might be more valuable to get people
interested in your study during the meeting than sharing _all_ your
results. You can always post more results on the mailing list where you can
have more discussion as well.

- jana

On Thu, Oct 22, 2020 at 5:33 AM Szilveszter Nadas <
[email-masked]> wrote:

> Hi Jana,
>
>
>
> If there is interest, I am happy to present about Congestion Control
> (un)fairness at the next iccrg. Mainly of BBRv2 to Cubic and DCTCP but not
> limited to that.
>
>
>
> I can present it in ~15 mins if needed, so a 20 min slot is OK, but if the
> slot is 30 min I can show more results.
>
>
>
> It would be based on these 3 papers + some extra results with TCP Prague
> and some extra considerations on CC fairness in general.
>
> http://ppv.elte.hu/buffer-sizing/
>
> http://ppv.elte.hu/scalable-cc-comp
>
> http://ppv.elte.hu/cc-independent-l4s/
>
>
>
> Cheers,
>
> Sz.
>
>
>
>
>
> *From:* iccrg <[email-masked]> *On Behalf Of * Jana Iyengar
> *Sent:* October 19, 2020 21:03
> *To:* iccrg IRTF list <[email-masked]>
> *Subject:* [iccrg] Agenda items for ICCRG meeting
>
>
>
> Hi all,
>
>
>
> Thanks, and looking forward to seeing you all,
>
> - jana
>

---

From: Szilveszter Nadas <[email-masked]>
Date: Tue, 10 Nov 2020 10:44:14 +0000

Hi Jana,

Thanks, we are still interested. We will prepare for a 20 min slot.

Sz.

From: Jana Iyengar <[email-masked]>
Sent: November 10, 2020 6:00
To: Szilveszter Nadas <[email-masked]>
Cc: iccrg IRTF list <[email-masked]>; Balázs Varga A <[email-masked]>; LAKI Sandor <[email-masked]>
Subject: Re: [iccrg] Agenda items for ICCRG meeting

Hi Szilveszter,

Apologies for taking a while to respond -- it's been a couple of difficult weeks. Are you still interested? I'd be happy to give you 20 minutes (include Q&A). In general, I think it might be more valuable to get people interested in your study during the meeting than sharing _all_ your results. You can always post more results on the mailing list where you can have more discussion as well.

- jana

On Thu, Oct 22, 2020 at 5:33 AM Szilveszter Nadas <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jana,

If there is interest, I am happy to present about Congestion Control (un)fairness at the next iccrg. Mainly of BBRv2 to Cubic and DCTCP but not limited to that.

I can present it in ~15 mins if needed, so a 20 min slot is OK, but if the slot is 30 min I can show more results.

It would be based on these 3 papers + some extra results with TCP Prague and some extra considerations on CC fairness in general.
http://ppv.elte.hu/buffer-sizing/
http://ppv.elte.hu/scalable-cc-comp
http://ppv.elte.hu/cc-independent-l4s/

Cheers,
Sz.

From: iccrg <[email-masked]<mailto:[email-masked]>> On Behalf Of Jana Iyengar
Sent: October 19, 2020 21:03
To: iccrg IRTF list <[email-masked]<mailto:[email-masked]>>
Subject: [iccrg] Agenda items for ICCRG meeting

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.