how to calculate packet loss from a binary TCPDUMP file

You can measure packet retransmits from the client to the server by counting the number of duplicate sequence numbers.

Packet retransmits from the server to the client can be measured by counting duplicate Ack numbers.

Note that a retransmit is triggered by more than just total loss (= timeout); if the remote machine rejects the packet, or the packet is corrupted, the local machine must also retransmit.

via networking – how to calculate packet loss from a binary TCPDUMP file – Server Fault.

I needed a way to measure this on a wifi network where packet loss can be very high and bursty.  This answer seems relatively simple to implement — just store off  ACK sequence numbers into an array of limited size and count how many times every new ACK matches in that array.  By monitoring this count I can determine where and when certain areas are getting bad and perhaps alert or alarm based upon a certain threshold.

Boost Satellite Bandwidth and End Jittery Videos

The tweaked version of TCP being honed by the MIT group and colleagues instead sends mathematical functions describing multiple packets so that a receiving device, such as a satellite terminal, can solve for missing ones without having to refetch them. “You transfer more packets than what you normally would, but you don’t have to retransmit,” Khan says.

via Boost Satellite Bandwidth and End Jittery Videos | MIT Technology Review.

This is a problem streaming in wifi networks with sketchy coverage  as well.  This is similar to a snippet I posted here on 10/25/2012 in reference to this article also from the MIT Technology Review  A Bandwidth Breakthrough

Apparently they’re still working on this TCP retransmission problem.

TCP ex Machina

Remy is a computer program that figures out how computers can best cooperate to share a network.

Remy creates end-to-end congestion-control algorithms that plug into the Transmission Control Protocol (TCP). These computer-generated algorithms can achieve higher performance and greater fairness than the most sophisticated human-designed schemes.

via TCP ex Machina.

MultiPath TCP

MultiPath TCP (MPTCP) is an effort towards enabling the simultaneous use of several IP-addresses/interfaces by a modification of TCP that presents a regular TCP interface to applications, while in fact spreading data across several subflows. Benefits of this include better resource utilization, better throughput and smoother reaction to failures. Slides – explaining MultiPath TCP – are available in .pdf and .pptx format. You can also have a look at our Google Techtalk about MPTCP.

via MultiPath TCP – Linux Kernel implementation : Main – Home Page browse.

Stanford researchers discover the ‘anternet’

On the surface, ants and the Internet don’t seem to have much in common. But two Stanford researchers have discovered that a species of harvester ants determine how many foragers to send out of the nest in much the same way that Internet protocols discover how much bandwidth is available for the transfer of data. The researchers are calling it the “anternet.”

via Stanford researchers discover the ‘anternet’.

Content-Centric Networking

CCN directly routes and delivers named pieces of content at the packet level of the network, enabling automatic and application-neutral caching in memory wherever it’s located in the network. The result? Efficient and effective delivery of content wherever and whenever it is needed.  Since the architecture enables these caching effects as an automatic side effect of packet delivery, memory can be used without building expensive application-level caching services.

via Content-Centric Networking – PARC, a Xerox company.

Google works on Internet standards with TCP proposals, SPDY standardization

Google’s focus is on reducing latency between client machines and servers, and in particular, reducing the number of round trips (either client to server and back to client, or vice versa) required. When data is sent over a TCP connection, its receipt must be acknowledged by the receiving end. The sending end can only send a certain number of packets before it must wait for an acknowledgement. The time taken to receive an acknowledged is governed by the round-trip time (RTT). With high bandwidth, high latency connections, clients and servers can end up spending most of their time waiting for acknowledgements, rather than sending packets.

via Google works on Internet standards with TCP proposals, SPDY standardization.

More far-reaching than these SSL tweaks is Google’s proposed alternative to the HTTP protocol that underpins the Web: SPDY.

TCP may keep its offered receive window closed indefinitely RFC 1122

Part of the Transmission Control Protocol TCP specification RFC 1122 allows a receiver to advertise a zero byte window, instructing the sender to maintain the connection but not send additional TCP payload data. The sender should then probe the receiver to check if the receiver is ready to accept data. Narrow interpretation of this part of the specification can create a denial-of-service vulnerability. By advertising a zero receive window and acknowledging probes, a malicious receiver can cause a sender to consume resources TCP state, buffers, and application memory, preventing the targeted service or system from handling legitimate connections.

via US-CERT Vulnerability Note VU#723308 – TCP may keep its offered receive window closed indefinitely RFC 1122.

The TCP Datagram

push flag (1 bits)

The push flag tells the receiving end of the tcp connection to “push” all buffered data to the receiving application. It basically says “done for now”.

via The TCP Datagram.

This would be the PSH flag that I needed to look up and found this site which makes for a good reference.