First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

comparison between two capture

  • retag add tags

Hello:

i have been troubleshooting between two methods of outlook client connecting to exchange and saw significant difference in performance. below is the info

10.10.10.1 is the server 192.168.0.1 is the client

below are the two captures

https://drive.google.com/open?id=1bmf... - slow

https://drive.google.com/open?id=1HrO... - fast (i had a wrong file earlier i corrected it)

In my assessment i saw obvious issue that slow transfer has lot more dup-ack re transmission compare to fast transfer but more importantly i noticed that on slow transfer receive window is very small on client compare to fast transfer. which was kind of strange but any other thoughts.

thanks

quest4answer's avatar
11
quest4answer
asked 2019-12-12 18:26:23 +0000, updated 2019-12-12 18:51:46 +0000
edit flag offensive 0 remove flag close merge delete

Comments

" two methods of outlook client connecting to exchange"
Can you describe the methods being tested?

Chuckc's avatar Chuckc (2019-12-12 19:13:52 +0000) edit
more
  • delete

mapi over http - slow rpc over http - fast

quest4answer's avatar quest4answer (2019-12-12 20:47:08 +0000) edit
more
  • delete
add a comment see more comments

1 Answer

0

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.

Philst's avatar
518
Philst
answered 2019-12-18 08:24:43 +0000, updated 2019-12-20 08:02:23 +0000
edit flag offensive 0 remove flag delete link
more

Comments

I just added a couple of paragraphs referring to those server "Dup-ACKs".

Philst's avatar Philst (2019-12-20 08:03:13 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer