If you get in touch via email, I'll send you my answer. Incidentally, I wrote a long answer to your '13543 - Outlook Performance' question but for some reason got an error every time I tried to post it (or even as a comment). You'll see similar 10 and 15 byte 'leftover' data packets at the end of other data 'blocks'. They all have the Push flag set and are at the end of a sequence of full-sized (1380) data packets making up a data 'block'. They are, in fact, very small data packets (5 data bytes in every one I examined) that have had the data removed - and hence look like ACKs.

This should be straightforward with tcpdump -r -w or using a wireshark display filter + export to new file.

First task, filter the traffic, generate new (filtered) capture files. Those hundreds of 'Dup-ACKs' (from the server) appear to be an artefact of your capturing/truncating mechanism. There's a bunch of different questions here. The 'slow' transfers exhibit the same behaviour as your other question - in that there are 2 TCP connections and the client, transfers 1 MB 'blocks' of data from one, then the other - alternating between them but never overlapping. Although the client advertises a receive window of 16 MB (slow) and 128 KB (fast), the sender appears to have a send buffer of only 32 KB. In both cases, the limiting factor is the amount of data that the sender is prepared to put on the wire before stopping and waiting for ACKs. 'slow' gets to 2.1 Mbps, again with BIF usually ~32 KB but sometimes 40 KB. 'fast' achieves around 1.6 Mbps, with bytes-in-flight (BIF) never above ~32 KB. I see the throughput in both these captures to be very similar.

Compare wireshark captures