linux-kernel - Re: Get amount of fast retransmissions from TCP info

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <8D257A7F-6045-46C5-AEED-A4630D10CD5A@simula.no>
Date:   Tue, 25 Apr 2017 00:20:05 +0200
From:   Andreas Petlund <apetlund@...ula.no>
To:     Neal Cardwell <ncardwell@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        Lars Erik Storbukås <storbukas.dev@...il.com>
Subject: Re: Get amount of fast retransmissions from TCP info


> On 24 Apr 2017, at 23:31, Lars Erik Storbukås <storbukas.dev@...il.com> wrote:
> 
> 2017-04-24 23:00 GMT+02:00 Neal Cardwell <ncardwell@...gle.com>:
>> On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås
>> <storbukas.dev@...il.com> wrote:
>>> 2017-04-24 21:42 GMT+02:00 Neal Cardwell <ncardwell@...gle.com>:
>>>> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås
>>>> <storbukas.dev@...il.com> 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