Subject: [iccrg] Agenda items for ICCRG meeting

From: Jana Iyengar <[email-masked]>
Date: Mon, 19 Oct 2020 12:02:49 -0700

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.

Thanks, and looking forward to seeing you all,
- jana

---

From: Szilveszter Nadas <[email-masked]>
Date: Thu, 22 Oct 2020 12:33:42 +0000

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,

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.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 31 Oct 2020 11:38:15 -0700

> 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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 31 Oct 2020 19:45:14 +0100

Hi,

I would ifnd this interesting and in scope for ICCRG.
Do you see this as being specific for a congestion control algorithm or 
generic?

I mean, is your idea to work on hot restart for BBR specifically?

Regards, marcelo

El 31/10/20 a las 19:38, Christian Huitema escribió:
> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 31 Oct 2020 19:51:53 +0100

> 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

Best regards
Michael

---

From: Christian Huitema <[email-masked]>
Date: Sat, 31 Oct 2020 12:50:40 -0700

> 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.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Sat, 31 Oct 2020 13:04:22 -0700

On 10/31/2020 11:45 AM, marcelo bagnulo braun wrote:
> Do you see this as being specific for a congestion control algorithm
> or generic?
>

The QUIC official document describes use of RENO, but QUIC
implementations mostly use Cubic and BBR. These algorithms use different
parameters: ssthresh for RENO, K, W_max and C for Cubic, observed
RTT_min and Bandwidth for BBR. So, yes, the way implementations use the
remembered connection data will vary with different algorithms, but the
science behind the decision ought to be generic. For example, if a data
path had a given data rate and RTT at time T, how likely is it that
setting the IW to a fraction of the observed BDP would cause problem at
at T+X? Can this be observed from just one observation, or do multiple
observations over a longer period of time help make better decisions?

-- Christian Huitema

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 31 Oct 2020 21:42:41 +0100

> On 31. Oct 2020, at 20:50, Christian Huitema <[email-masked]> wrote:
> 
> 
Storing such parameters in FreeBSD is done in the hostcache.
tuexen@bsd6:~ % sysctl net.inet.tcp.hostcache.list
net.inet.tcp.hostcache.list: 
IP address        MTU  SSTRESH      RTT   RTTVAR     CWND SENDPIPE RECVPIPE HITS  UPD  EXP
158.69.0.38         0        0     96ms     21ms    14999        0        0    0    1 1800
223.71.78.154       0        0    327ms     70ms    14999        0        0    0    1 2400
205.185.115.183     0        0    136ms     13ms    15399        0        0    0    7 1200

One would need to extend it for other CC relevant parameters and provide an interface
to userland. The hostcache is also filled from other protocols than TCP, SCTP for example.
FreeBSD uses only RTT, RTTVAR, and SSTHRESH when initializing a TCP connection. From
netstat -s -p TCP:
	13658 connections established (including accepts)
		10468 times used RTT from hostcache
		10468 times used RTT variance from hostcache
		2318 times used slow-start threshold from hostcache

Best regards
Michael