Opened 3 years ago

Last modified 8 months ago

#24694 new enhancement

sched: Use the socket RTT in KIST to compute a more accurate extra space

Reported by: dgoulet Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-sched, kist, 034-triage-20180328, 034-removed-20180328
Cc: pastly, yawning Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


This comes from a discussion in #24665 that Yawning started:

Assuming the scheduler is called significantly faster than the RTT of most links (read that as "If 10 ms is lower than the RTT of most if not all links"), you can/should reduce sock_buf_size_factor as well, because you aren't going to get a full congestion window worth of ACKs back between scheduler calls in common cases.

There isn't a good "one size fits all" solution. Setting it too low will gimp performance on fast low latency links, setting it too high right now bloats the various buffers. I would personally opt more toward avoiding the latter given all the Fun that's happening.

In the struct tcp_info we use in KIST, tcpi_rtt gives the smoothed RTT estimate (and tcpi_rttvar the RTT variance if you need it), which is probably sufficient to give a better reasonable guess here, as a first pass, I would recommend doing something based on the the scheduler interval to smoothed RTT ratio, with a hard maximum at 1.0.

Child Tickets

Change History (10)

comment:1 Changed 3 years ago by yawning

Cc: yawning added

comment:2 Changed 3 years ago by yawning

ISTR suggesting to look at tcpi_snd_ssthresh as well back in the original KIST ticket as well, but I'll bring it up because this ticket is about "making better capacity decisions".

While my suggestion was to increase the scheduling frequency for a connection while it was in Slow Start (because SND.CWND will double on each ACK), instead I would probably be less aggressive about feeding a connection more data while SND.CWND < ssthresh (because SND.CWND will overshoot what is possible by the link and you're way over buffered at that point).

My assertion here is that while a connection is in slow start, the congestion window is an insufficiently accurate estimate of actual link capacity to serve as a good measure for how much buffering to do.

comment:3 Changed 3 years ago by dgoulet

Owner: set to dgoulet
Status: newassigned

comment:4 Changed 3 years ago by dgoulet

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

Move 033 ticket I own to 034

comment:5 Changed 3 years ago by nickm

Keywords: 034-triage-20180328 added

comment:6 Changed 3 years ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:7 Changed 3 years ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

comment:8 Changed 17 months ago by gaba

Owner: dgoulet deleted

Releasing some old tickets.

comment:9 Changed 16 months ago by cypherpunks

you recommend to reduce both the same multiplier so something like:

# KISTSchedRunInterval KISTSchedRunInterval __NUM__ msec
#     If KIST or KISTLite is used in the Schedulers option, this controls at which
#     interval the scheduler tick is. If the value is 0 msec, the value is taken
#     from the consensus if possible else it will fallback to the default 10
#     msec. Maximum possible value is 100 msec. (Default: 0 msec)
KISTSchedRunInterval    1 msec
# KISTSockBufSizeFactor KISTSockBufSizeFactor __NUM__
#     If KIST is used in Schedulers, this is a multiplier of the per-socket
#     limit calculation of the KIST algorithm. (Default: 1.0)
KISTSockBufSizeFactor   0.1


comment:10 Changed 8 months ago by teor

Status: assignednew

Change tickets that are assigned to nobody to "new".

Note: See TracTickets for help on using tickets.