# 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: (Sequence # of sender) + (TCP Length of sender) - (SACK right edge of receiver) = Value #1 (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 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 ♦♦

 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)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 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 ♦
 toggle preview community wiki:

By Email:

Markdown Basics

• *italic* or _italic_
• **bold** or __bold__
• image?![alt text](/path/img.jpg "title")
• numbered list: 1. Foo 2. Bar
• to add a line break simply add two spaces to where you would like the new line to be.
• basic HTML tags are also supported

Question tags:

×752
×10

question asked: 11 Feb '15, 13:15

question was seen: 6,660 times

last updated: 06 Mar '17, 19:05

### Related questions

p​o​w​e​r​e​d by O​S​Q​A