This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Bytes in Flight calculations

0

How does Wireshark calculate Bytes in Flight (BIF)? Do the BIF also consider the SACK left-edge and right-edge values? I have an 19MB file that I would like to share, but do not see a way to attach the file to this post. Here is a general formula that I am using to determine BIF assuming with SACK:

  1. (Sequence # of sender) + (TCP Length of sender) - (SACK right edge of receiver) = Value #1
  2. (SACK left edge of receiver) - (Last TCP ACK # from receiver) = Value #2

BIF = (Value #1) + (Value #2)

Are the above equations correct? Please correct any of the above equations as needed.

asked 11 Feb '15, 13:15

Amato_C's gravatar image

Amato_C
1.1k●14●20●32
accept rate: 14%

Put it on http://www.cloudshark.org, and sanitize it with TraceWrangler first if necessary.

(11 Feb '15, 13:16) Jasper ♦♦

2 Answers:

1

At the point you mention, there are 9 packets missing, forming a data gap between #264 and #270. It would appear that these really were missing from the flow, because SACKs #283-#293 report that missing data. #308-#316 are the TCP retransmissions that fill that gap.

According to the bug report, this is why Wireshark doesn't count them in the BIF calculation.

There are also 5 packets missing between #274 and #275. However, these are selectively acknowledged, very soon after, by those same SACKs mentioned above.

This capture is a treasure trove of interesting behaviour.

There are also many examples of:

  • Packets retransmitted at the radio level, where we see the original in the trace (eg, #303 and #317 ; #352-#360 are repeats of #308-#316).

  • This happens for ACKs too (eg, #2225-#2233, then #2236-#2244).

  • Packets retransmitted at the radio level, where we DON'T see the original in the trace (eg, #332-#336).

  • Packets unnecessarily retransmitted at the TCP/IP level, where we see the original in the trace and they are ACKed. These also trigger Duplicate SACKs (eg, #352-#360 are retransmissions of #308-#316, #395 is a D-SACK for #360).

  • Packets seen in the trace but not seen at the TCP/IP level by the receiver (eg, #343 is selectively not-ACKed but the radio retransmission, #396, does get ACKed. Likewise for #346/#397 and #347/#398).

  • Transmit Window "inflation", where the sender outputs more "packets in flight" in response to many SACKs.

I guess that your capturing WiFi device is closer to the access point than your real receiver (since we see packets that the receiver doesn't - at both the radio and TCP/IP level). Your capture device also drops some real packets that the receiver does see.

answered 02 Mar '17, 23:59

Philst's gravatar image

Philst
431●1●6●16
accept rate: 27%

edited 05 Mar '17, 18:05

@Philst = thank you for the detailed analysis. By showing the flow analysis in NetData, it has become evident the complexity of the capture goes beyond a miscalculation in Bytes-in-Flight.

(06 Mar '17, 19:05) Amato_C

0

As I understand the code, Wireshark sums up the TCP length of all unACKed frames by walking throuh a list of those unACKed frames (ual).

File: packet-tcp.c

    /* how many bytes of data are there in flight after this frame
     * was sent
     */
    ual=tcpd->fwd->segments;
    if (tcp_track_bytes_in_flight && seglen!=0 && ual && tcpd->fwd->valid_bif) {
        guint32 first_seq, last_seq, in_flight;

    first_seq = ual->seq - tcpd->fwd->base_seq;
    last_seq = ual->nextseq - tcpd->fwd->base_seq;
    while (ual) {
        if ((ual->nextseq-tcpd->fwd->base_seq)>last_seq) {
            last_seq = ual->nextseq-tcpd->fwd->base_seq;
        }
        if ((ual->seq-tcpd->fwd->base_seq)<first_seq) {="" first_seq="ual-">seq-tcpd->fwd->base_seq;
        }
        ual = ual->next;
    }
    in_flight = last_seq-first_seq;

    if (in_flight>0 && in_flight<2000000000) {
        if(!tcpd->ta) {
            tcp_analyze_get_acked_struct(pinfo->fd->num, seq, ack, TRUE, tcpd);
        }
        tcpd->ta->bytes_in_flight = in_flight;
    }
}

SLE and SRE are not considered. You can see it pretty good in a SACK sample capture with packet loss.

http://packetlife.net/captures/TCP_SACK.cap

Add a column for bytes in flight to see it (Frames #30 - #39).

Regards
Kurt

answered 11 Feb ‘15, 15:38

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

Hi Kurt, Thank you for the code and example. It is clear now that SACK is not used to determine the Bytes-in-Flight (BIF) calculation. However, I am still seeing a problem with the BIF calculation with my Wireshark trace.
First, let’s look at the capture file you provided: “TCP_SACK.cap”. Looking at packets #36-#38, the BIF calculation is: (Sequence # of sender) + (TCP Length of sender) - (ACK of receiver) = 23169 + 1222 - 17377 = 7014 This is the exact number reported as BIF by Wireshark on packet #38.

Now I will perform the same analysis using the file at: https://drive.google.com/file/d/0B3IDBN3nIwLzeVViaXhUVkFjVGc/view?usp=sharing

Please download and view the file: “Stitcher-Only-TCP-Traffic-Stream3.pcap” Let’s look at packets #293-#294: (Sequence # of sender) + (TCP Length of sender) - (ACK of receiver) = 211914 + 1448 - 174266 = 39096 However, packet #294 is reporting BIF = 26064 That is a difference of 39096 - 26064 = 13032 bytes or (13032/1448) = 9 packets

Why such the large discrepancy?

(12 Feb ‘15, 08:06) Amato_C

Wireshark reporting incorrect bytes-in-flight values is a known issue. Please reference Bug ID #7703.

(16 Feb ‘15, 07:08) Amato_C

yep, looks like there is ‘room for improvement’ ;-)

(16 Feb ‘15, 12:48) Kurt Knochner ♦