Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S978743AbdDXWUS (ORCPT ); Mon, 24 Apr 2017 18:20:18 -0400 Received: from mail-lf0-f47.google.com ([209.85.215.47]:33845 "EHLO mail-lf0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755949AbdDXWUK (ORCPT ); Mon, 24 Apr 2017 18:20:10 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Get amount of fast retransmissions from TCP info From: Andreas Petlund In-Reply-To: Date: Tue, 25 Apr 2017 00:20:05 +0200 Cc: LKML , Netdev , =?utf-8?Q?Lars_Erik_Storbuk=C3=A5s?= Message-Id: <8D257A7F-6045-46C5-AEED-A4630D10CD5A@simula.no> References: To: Neal Cardwell X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v3OMKgc9004371 Content-Length: 3874 Lines: 99 > On 24 Apr 2017, at 23:31, Lars Erik Storbukås wrote: > > 2017-04-24 23:00 GMT+02:00 Neal Cardwell : >> On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås >> wrote: >>> 2017-04-24 21:42 GMT+02:00 Neal Cardwell : >>>> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås >>>> wrote: >>>>> I'm trying to get amount of congestion events in TCP caused by >>>>> DUPACK's (fast retransmissions), and can't seem to find any variable >>>>> in the TCP info struct which hold that value. There are three >>>>> variables in the TCP info struct that seem to hold similar congestion >>>>> values: __u8 tcpi_retransmits;__u32 tcpi_retrans; __u32 >>>>> tcpi_total_retrans; >>>>> >>>>> Does anyone have any pointers on how to find this value in the TCP code? >>>>> >>>>> Please CC me personally if answering this question. Any help is >>>>> greatly appreciated. >>>> >>>> [I'm cc-ing the netdev list.] >>>> >>>> Do you need this per-socket? On a per-socket basis, I do not think >>>> there are separate totals for fast retransmits and timeout >>>> retransmits. >>>> >>>> If a global number is good enough, then you can get that number from >>>> the global network statistics. In "nstat" output they look like: >>>> >>>> TcpExtTCPFastRetrans = packets sent in fast retransmit / fast recovery >>>> >>>> TcpExtTCPSlowStartRetrans = packets sent in timeout recovery >>>> >>>> It sounds like TcpExtTCPFastRetrans is what you are after. >>>> >>>> Hope that helps, >>>> neal >>> >>> Thanks for your answer Neal. >>> >>> Yes, I need this information per-socket. What would be the most >>> appropriate place to update this value? >> >> Is this for a custom kernel you are building? Or are you proposing >> this for upstream? > > This is currently for a custom kernel. > >> IMHO the best place to add this for your custom kernel would be in >> _tcp_retransmit_skb() around the spot with the comment "Update global >> and local TCP statistics". Something like: >> >> /* Update global and local TCP statistics. */ >> ... >> tp->total_retrans += segs; >> if (icsk->icsk_ca_state == TCP_CA_Loss) >> tp->slow_retrans += segs; >> else >> tp->fast_retrans += segs; >> > > Excellent. That seems like a logical place. > >>> If none of the variables (mentioned above) contain any value in >>> regards to fast retransmits, what does the different values represent? >> >> tcpi_retransmits: consecutive retransmits of lowest-sequence outstanding packet >> >> tcpi_retrans: retransmitted packets estimated to be in-flight in the network now >> >> tcpi_total_retrans: total number of retransmitted packets over the >> life of the connection >> >> Can you sketch out why you need to have separate counts for fast >> retransmits and timeout/slow-start retransmits? >> >> neal > > I'm working on the implementation of a Deadline Aware, Less than Best > Effort framework proposed by David A. Hayes, David Ros, Andreas > Petlund. A framework for adding both LBE behaviour and awareness of > “soft” delivery deadlines to any congestion control (CC) algorithm, > whether loss-based, delay- based or explicit signaling-based. This > effectively allows it to turn an arbitrary CC protocol into a > scavenger protocol that dynamically adapts its sending rate to network > conditions and remaining time before the deadline, to balance > timeliness and transmission aggressiveness. > Just for the record, the paper is not publicly available yet, so it’s a bit hard to find:) It will be published in IFIP Networking in June. We will make it available as soon as the conference regulations allows. You can find the abstract here: https://www.simula.no/publications/framework-less-best-effort-congestion-control-soft-deadlines Cheers, Andreas Petlund