Opened 4 months ago

Last modified 10 days ago

#24694 assigned enhancement

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

Reported by: dgoulet Owned by: dgoulet
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:

Description

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 (7)

comment:1 Changed 4 months ago by yawning

Cc: yawning added

comment:2 Changed 4 months 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 months ago by dgoulet

Owner: set to dgoulet
Status: newassigned

comment:4 Changed 3 months 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 weeks ago by nickm

Keywords: 034-triage-20180328 added

comment:6 Changed 3 weeks ago by nickm

Keywords: 034-removed-20180328 added

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

comment:7 Changed 10 days 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.

Note: See TracTickets for help on using tickets.