> -----Original Message----- > From: Koen De Schepper (Nokia) <[email protected]> > Sent: Wednesday, July 1, 2026 6:17 PM > To: Alexei Starovoitov <[email protected]>; Chia-Yu Chang (Nokia) > <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Subject: RE: [PATCH v3 net-next 1/1] tcp: Replace min_tso_segs() with > tso_segs() CC callback [...] > > > You have to explain why Prague CC cannot rely on autosizing. > > To me it sounds like a red flag. autosizing logic was there for a decade, > > if not more. > > And now you're arguing that your CC logic is special and it deserves new > > API and breakage of existing convention. > > Maybe you should step back and reconsider. > > Hi Alexei, > > >>You have to explain why Prague CC cannot rely on autosizing. > >>To me it sounds like a red flag. autosizing logic was there for a decade, > >>if not more. > >>And now you're arguing that your CC logic is special and it deserves new > >>API and breakage of existing convention. > >>Maybe you should step back and reconsider. > > The objective behind Prague auto-sizing is that the TSO burst should not > create a queuing latency bigger than 250us, on a bottleneck link rate that is > the pacing rate. The rationale is that the L4S AQMs are allowed to have a > very small threshold (often somewhere between 0.5ms to 1ms). When the pacing > rate is 96Mbps we start allowing TSO size of 2, etc... Below 96Mbps the TSO > size is 1, and below 48Mbps the potential serialization time of a single > packet is bigger than 250us. You will also see in other patches that we limit > the serialization time of one MTU to 10ms when the rate goes lower than 1Mbps > by limiting the max MTU (going down to a minimum pacing rate of 100kbps as > the minimum sending rate). > L4S AQMs are designed with these parameters in mind. As AQMs usually work > packet per packet and evaluate waiting time in the queue, definitely the > minimum inter-packet departure time needs to be bigger than the serialization > time - 0.5ms or packets will get marked without necessarily using the full > link capacity. > > The current autosizing algo has as objective to scale the TSO size depending > on both pacing rate and RTT. It targets a 1ms queue delay burst when the RTT > is bigger than 3ms, but when the RTT is smaller it further increases the > TSO-size. The rationale behind this is that a bigger TSO-size results in a > bigger chance of loss, and that loss is easier to retransmit if the RTT is > smaller. > > So, the current algorithm does not line up with the Prague expectations. Is > allows bursts of 1ms instead of 250us and it allows even bigger bursts if the > minimum RTT is below 3ms (for instance 27ms burst at 10Mbps and 1ms RTT). > > I see following options how to include the Prague requirement of 250us burst > instead of 1ms and not increasing TSO if the RTT is lower than 3ms: > - Let Prague do the calculation and set the desired TSO size > - previously done with an extra hook to overwrite the autosize, but it > was already commented to avoid the extra hook > - change the existing hook and add a fixed or max TSO size (current > patch did the fixed TSO overruling, maybe a max could be more general as it > would always be lower than the current calculated autosize) > - Add a cc settable parameter max-TSO-burst-time to let the current autosize > do the extra calculation and take this extra check into account > - we are open to any other suggestions... > > Koen.
Hi Alexei, I see Koen had responded to your question in above email. Would you please let us know what's the suggested to proceed? Thanks! Chia-Yu
