I see the throughput in both these captures to be very similar.
"fast" achieves around 1.6 Mbps, with bytes-in-flight (BIF) never above ~32 KB.
"slow" gets to 2.1 Mbps, again with BIF usually ~32 KB but sometimes 40 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. 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.
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.
Those hundreds of "Dup-ACKs" (from the server) appear to be an artefact of your capturing/truncating mechanism. 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. 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".
You'll see similar 10 and 15 byte "leftover" data packets at the end of other data "blocks".
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). If you get in touch via email, I'll send you my answer.
" two methods of outlook client connecting to exchange"
Can you describe the methods being tested?
mapi over http - slow rpc over http - fast