4

I would want to know the meaning of some items in the ss command output. Eg:

# sudo   ss -iepn '( dport = :3443 )'

Netid      State      Recv-Q      Send-Q             Local Address:Port              Peer Address:Port      
tcp        ESTAB      0           0                  192.168.43.39:45486              190.0.2.1:443       users:(("rocketchat-desk",pid=28697,fd=80)) timer:(keepalive,11sec,0) uid:1000 ino:210510085 sk:16f1 <->
         ts sack cubic wscale:7,7 rto:573 rtt:126.827/104.434 ato:40 mss:1388 pmtu:1500 rcvmss:1388 advmss:1448 cwnd:10 bytes_sent:12904 bytes_retrans:385 bytes_acked:12520 bytes_received:13322 segs_out:433 segs_in:444 data_segs_out:215 data_segs_in:253 send 875.5Kbps lastsnd:18722 lastrcv:18723 lastack:18662 pacing_rate 1.8Mbps delivery_rate 298.1Kbps delivered:216 busy:16182ms retrans:0/10 dsack_dups:10 rcv_rtt:305 rcv_space:14480 rcv_ssthresh:6
CLOSE-WAIT      1           0                [2800:810:54a:7f0::1000]:37844                                     [2800:3f0:4002:803::200a]:443                    users:(("plasma-browser-",pid=16020,fd=175)) uid:1000 ino:90761 sk:1d -->
         ts sack cubic wscale:8,7 rto:222 rtt:21.504/5.045 ato:40 mss:1348 pmtu:1500 rcvmss:1208 advmss:1428 cwnd:10 bytes_sent:1470 bytes_acked:1471 bytes_received:11214 segs_out:20 segs_in:20 data_segs_out:8 data_segs_in:13 send 5014881bps lastsnd:96094169 lastrcv:96137280 lastack:96094142 pacing_rate 10029464bps delivery_rate 1363968bps delivered:9 app_limited busy:91ms rcv_space:14280 rcv_ssthresh:64108 minrtt:17.458

Mainly items missing in ss man page, I made some guesses, please correct me if I'm wrong:

  • rcvmss: I wonder is MMS receidev
  • advmss: ?
  • app_limited: ?
  • busy: ?
  • retrans: ?
  • dsack_dups: Duplicated segments?
  • minrtt: Minimum RTT achieved in the socket?
4

Meaning of some of these fields can be deduced from source code of ss and Linux kernel. Information you see is printed by tcp_show_info() function in iproute2/misc/ss.c.

advmss:

In ss.c:

s.advmss     = info->tcpi_advmss;
(...)
    if (s->advmss)
        out(" advmss:%d", s->advmss);

In linux/include/linux/tcp.h:

u16 advmss;     /* Advertised MSS           */

app_limited:

In ss.c:

s.app_limited = info->tcpi_delivery_rate_app_limited;
(..)
if (s->app_limited)
   out(" app_limited");

That one is not documented in linux/include/uapi/linux/tcp.h in Linux:

struct tcp_info {
(...)
    __u8    tcpi_delivery_rate_app_limited:1;

but surprisingly we can find some information in the commit that introduced it:

commit eb8329e0a04db0061f714f033b4454326ba147f4
Author: Yuchung Cheng <ycheng@google.com>
Date:   Mon Sep 19 23:39:16 2016 -0400

    tcp: export data delivery rate

    This commit export two new fields in struct tcp_info:

      tcpi_delivery_rate: The most recent goodput, as measured by
        tcp_rate_gen(). If the socket is limited by the sending
        application (e.g., no data to send), it reports the highest
        measurement instead of the most recent. The unit is bytes per
        second (like other rate fields in tcp_info).

      tcpi_delivery_rate_app_limited: A boolean indicating if the goodput
        was measured when the socket's throughput was limited by the
        sending application.

    This delivery rate information can be useful for applications that
    want to know the current throughput the TCP connection is seeing,
    e.g. adaptive bitrate video streaming. It can also be very useful for
    debugging or troubleshooting.

A quick git blame in ss.c confirms that app_limited was added after tcpi_delivery_rate_app_limited was added to kernel.

busy:

In ss.c:

s.busy_time = info->tcpi_busy_time;
(..)
    if (s->busy_time) {
        out(" busy:%llums", s->busy_time / 1000);

And in include/uapi/linux/tcp.h in Linux it says:

struct tcp_info {
(...)
    __u64   tcpi_busy_time;      /* Time (usec) busy sending data */

retrans:

In ss.c:

s.retrans    = info->tcpi_retrans;
s.retrans_total  = info->tcpi_total_retrans;
(...)
    if (s->retrans || s->retrans_total)
        out(" retrans:%u/%u", s->retrans, s->retrans_total);

tcpi_total_retrans is not described in linux/include/uapi/linux/tcp.h:

struct tcp_info {
(...)
    __u32   tcpi_total_retrans;

but it's used in tcp_get_info():

void tcp_get_info(struct sock *sk, struct tcp_info *info)
{
    const struct tcp_sock *tp = tcp_sk(sk); /* iff sk_type == SOCK_STREAM */
(...)
    info->tcpi_total_retrans = tp->total_retrans;

And in linux/include/linux/tcp.h it says:

struct tcp_sock {
(...)
    u32 total_retrans;  /* Total retransmits for entire connection */

tcpi_retrans is also not described but reading tcp_get_info() again we see:

info->tcpi_retrans = tp->retrans_out;

And in linux/include/linux/tcp.h:

struct tcp_sock {
(...)
    u32 retrans_out;    /* Retransmitted packets out        */

dsack_dups:

In ss.c:

s.dsack_dups = info->tcpi_dsack_dups;
(...)
    if (s->dsack_dups)
        out(" dsack_dups:%u", s->dsack_dups);

In include/uapi/linux/tcp.h in Linux:

struct tcp_info {
(...)
__u32   tcpi_dsack_dups;     /* RFC4898 tcpEStatsStackDSACKDups */

And in https://www.ietf.org/rfc/rfc4898.txt:

The number of duplicate segments reported to the local host by D-SACK blocks.

| improve this answer | |
  • This was extremely helpful, thanks! You might also add additional stats, ie busy, sndbuf_limited from patchwork.ozlabs.org/patch/701622 – Alec Istomin Nov 9 '19 at 0:25
  • So, does app_limited belongs to `delivered:9 in the example? – sebelk Dec 12 '19 at 13:59
1

MSS normally stands for Maximum Segment Size.

rcvmss: maximum segment size you let peers know you will accept

advmss: advertise maximum segment size

app_limited: limit TCP flows with application-limiting in request or responses

busy: TCP connection is busy??

retrans: re-transmission timer. If the sender of a data packet does not receive ack before the timer expires, it will try to retransmit the packet

dsack_dups: duplicate selective acknowledgement

minrtt: minimum round trip time, min time a packet to travel from source to dest

Let me know if any of these are wrong and I will correct.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.